- 09 Sep, 2020 23 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Rewrite inner header IPv6 in ICMPv6 messages in ip6t_NPT, from Michael Zhou. 2) do_ip_vs_set_ctl() dereferences uninitialized value, from Peilin Ye. 3) Support for userdata in tables, from Jose M. Guisado. 4) Do not increment ct error and invalid stats at the same time, from Florian Westphal. 5) Remove ct ignore stats, also from Florian. 6) Add ct stats for clash resolution, from Florian Westphal. 7) Bump reference counter bump on ct clash resolution only, this is safe because bucket lock is held, again from Florian. 8) Use ip_is_fragment() in xt_HMARK, from YueHaibing. 9) Add wildcard support for nft_socket, from Balazs Scheidler. 10) Remove superfluous IPVS dependency on iptables, from Yaroslav Bolyukin. 11) Remove unused definition in ebt_stp, from Wang Hai. 12) Replace CONFIG_NFT_CHAIN_NAT_{IPV4,IPV6} by CONFIG_NFT_NAT in selftests/net, from Fabian Frederick. 13) Add userdata support for nft_object, from Jose M. Guisado. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Randy Dunlap authored
Fix typo/spello of "functionality". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jon Mason <jdmason@kudzu.us> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: Jiri Kosina <trivial@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Fix typo/spello of "functions". Signed-off-by:
-
Wei Wang authored
Currently, ipv6 stack does not do any TOS reflection. To make the behavior consistent with v4 stack, this commit adds TOS reflection in tcp_v6_reqsk_send_ack() and tcp_v6_send_reset(). We clear the lower 2-bit ECN value of the received TOS in compliance with RFC 3168 6.1.5 robustness principles. Signed-off-by:
Wei Wang <weiwan@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fsDavid S. Miller authored
David Howells says: ==================== rxrpc: Allow more calls to same peer Here are some development patches for AF_RXRPC that allow more simultaneous calls to be made to the same peer with the same security parameters. The current code allows a maximum of 4 simultaneous calls, which limits the afs filesystem to that many simultaneous threads. This increases the limit to 16. To make this work, the way client connections are limited has to be changed (incoming call/connection limits are unaffected) as the current code depends on queuing calls on a connection and then pushing the connection through a queue. The limit is on the number of available connections. This is changed such that there's a limit[*] on the total number of calls systemwide across all namespaces, but the limit on the number of client connections is removed. Once a call is allowed to proceed, it finds a bundle of connections and tries to grab a call slot. If there's a spare call slot, fine, otherwise it will wait. If there's already a waiter, it will try to create another connection in the bundle, unless the limit of 4 is reached (4 calls per connection, giving 16). A number of things throttle someone trying to set up endless connections: - Calls that fail immediately have their conns deleted immediately, - Calls that don't fail immediately have to wait for a timeout, - Connections normally get automatically reaped if they haven't been used for 2m, but this is sped up to 2s if the number of connections rises over 900. This number is tunable by sysctl. [*] Technically two limits - kernel sockets and userspace rxrpc sockets are accounted separately. ==================== Signed-off-by: -
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tc35815_init_queues()' GFP_ATOMIC must be used because it can be called from 'tc35815_restart()' where some spinlock are taken. The call chain is: tc35815_restart --> tc35815_clear_queues --> tc35815_init_queues @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'rr_init_one()' GFP_KERNEL can be used because it is a probe function and no spinlock is taken in the between. When memory is allocated in 'rr_open()' GFP_KERNEL can be used because it is a '.ndo_open' function (see struct net_device_ops) and no spinlock is taken in the between. '.ndo_open' functions are synchronized using the rtnl_lock() semaphore. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
-
Edward Cree authored
The code recently moved into this file contained a number of coding style issues, about which checkpatch and xmastree complained. Fix them. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Stephen reported the following warning: net/bridge/br_multicast.c: In function 'br_multicast_find_port': net/bridge/br_multicast.c:1818:21: warning: unused variable 'br' [-Wunused-variable] 1818 | struct net_bridge *br = mp->br; | ^~ It happens due to bridge's mlock_dereference() when lockdep isn't defined. Silence the warning by annotating the variable as __maybe_unused. Fixes: 0436862e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): net/netlabel/netlabel_calipso.c:438: warning: Excess function parameter 'audit_secid' description in 'calipso_doi_remove' net/netlabel/netlabel_calipso.c:605: warning: Excess function parameter 'reg' description in 'calipso_req_delattr' Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/control.c:709: warning: Excess function parameter 'msg_skb' description in 'i2400m_msg_to_dev' This parameter is not in use. Remove it. Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'netdev' description in 'bnx2x_setup_tc' drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'tc' description in 'bnx2x_setup_tc' Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): net/ipv4/cipso_ipv4.c:510: warning: Excess function parameter 'audit_secid' description in 'cipso_v4_doi_remove' Reported-by:
-
Wei Xu authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_rx_fastforward’: drivers/net/ethernet/smsc/smsc911x.c:1199:16: warning: variable ‘temp’ set but not used [-Wunused-but-set-variable] drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_eeprom_write_location’: drivers/net/ethernet/smsc/smsc911x.c:2058:6: warning: variable ‘temp’ set but not used [-Wunused-but-set-variable] Signed-off-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: misc updates There are some misc updates for the HNS3 ethernet driver. ==================== Reviewed-by: Jakub Kicinski <kuba@kernel.org Signed-off-by: -
Guojia Liao authored
hns3_update_promisc_mode is defined, but not be used, so remove it. Signed-off-by:
Guojia Liao <liaoguojia@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
There are several macros related queue defined, but never used, so remove them. Signed-off-by:
-
Huazhong Tan authored
'tc_num_last_time' is defined, but never used, so remove it. Reported-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Huazhong Tan authored
'io_base' has been defined and initialized, but never used, so remove it. Signed-off-by:
-
Guangbin Huang authored
The member link of struct hclge_mac stores the link status of MAC and PHY if PHY exists, but its annotation uses word "exit", so fix it. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Guangbin Huang authored
When reset fails, if there are some pending jobs for the periodic service task, it does not do anything except print error each time the task is scheduled. So skip the periodic service task if reset failed. Signed-off-by:
-
Huazhong Tan authored
Since variable send_msg and ret only used in if branch, so move their definition into the if branch. Signed-off-by:
-
Tom Rix authored
Reviewing the error handling in tcf_action_init_1() most of the early handling uses err_out: if (cookie) { kfree(cookie->data); kfree(cookie); } before cookie could ever be set. So skip the unnecessay check. Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
- 08 Sep, 2020 8 commits
-
-
David Howells authored
Allow the number of parallel connections to a machine to be expanded from a single connection to a maximum of four. This allows up to 16 calls to be in progress at the same time to any particular peer instead of 4. Signed-off-by:David Howells <dhowells@redhat.com>
-
David Howells authored
Rewrite the rxrpc client connection manager so that it can support multiple connections for a given security key to a peer. The following changes are made: (1) For each open socket, the code currently maintains an rbtree with the connections placed into it, keyed by communications parameters. This is tricky to maintain as connections can be culled from the tree or replaced within it. Connections can require replacement for a number of reasons, e.g. their IDs span too great a range for the IDR data type to represent efficiently, the call ID numbers on that conn would overflow or the conn got aborted. This is changed so that there's now a connection bundle object placed in the tree, keyed on the same parameters. The bundle, however, does not need to be replaced. (2) An rxrpc_bundle object can now manage the available channels for a set of parallel connections. The lock that manages this is moved there from the rxrpc_connection struct (channel_lock). (3) There'a a dummy bundle for all incoming connections to share so that they have a channel_lock too. It might be better to give each incoming connection its own bundle. This bundle is not needed to manage which channels incoming calls are made on because that's the solely at whim of the client. (4) The restrictions on how many client connections are around are removed. Instead, a previous patch limits the number of client calls that can be allocated. Ordinarily, client connections are reaped after 2 minutes on the idle queue, but when more than a certain number of connections are in existence, the reaper starts reaping them after 2s of idleness instead to get the numbers back down. It could also be made such that new call allocations are forced to wait until the number of outstanding connections subsides. Signed-off-by: -
David Howells authored
Impose a maximum on the number of client rxrpc calls that are allowed simultaneously. This will be in lieu of a maximum number of client connections as this is easier to administed as, unlike connections, calls aren't reusable (to be changed in a subsequent patch).. This doesn't affect the limits on service calls and connections. Signed-off-by: -
Jose M. Guisado Gomez authored
Enables storing userdata for nft_object. Initially this will store an optional comment but can be extended in the future as needed. Adds new attribute NFTA_OBJ_USERDATA to nft_object. Signed-off-by:
Jose M. Guisado Gomez <guigom@riseup.net> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Fabian Frederick authored
Replace old parameters with global NFT_NAT from commit db8ab388 ("netfilter: nf_tables: merge ipv4 and ipv6 nat chain types") Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Wang Hai authored
BPDU_TYPE_TCN is never used after it was introduced. So better to remove it. Reported-by:
-
Vladimir Oltean authored
Commit 72579e14 ("net: dsa: don't fail to probe if we couldn't set the MTU") changed, for some reason, the "err && err != -EOPNOTSUPP" check into a simple "err". This causes the MTU warning to be printed even for drivers that don't have the MTU operations implemented. Fix that. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
slave_dev->name is only populated at this stage if it was specified through a label in the device tree. However that is not mandatory. When it isn't, the error message looks like this: [ 5.037057] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.044672] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.052275] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.059877] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d which is especially confusing since the error gets printed on behalf of the DSA master (fsl_enetc in this case). Printing an error message that contains a valid reference to the DSA port's name is difficult at this point in the initialization stage, so at least we should print some info that is more reliable, even if less user-friendly. That may be the driver name and the hardware port index. After this change, the error is printed as: [ 6.051587] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 0 [ 6.061192] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 1 [ 6.070765] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 2 [ 6.080324] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 3 Signed-off-by:
-
- 07 Sep, 2020 9 commits
-
-
Jakub Kicinski authored
This patch is born out of an investigation into which IEEE statistics correspond to which struct rtnl_link_stats64 members. Turns out that there seems to be reasonable consensus on the matter, among many drivers. To save others the time (and it took more time than I'm comfortable admitting) I'm adding comments referring to IEEE attributes to struct rtnl_link_stats64. Up until now we had two forms of documentation for stats - in Documentation/ABI/testing/sysfs-class-net-statistics and the comments on struct rtnl_link_stats64 itself. While the former is very cautious in defining the expected behavior, the latter feel quite dated and may not be easy to understand for modern day driver author (e.g. rx_over_errors). At the same time modern systems are far more complex and once obvious definitions lost their clarity. For example - does rx_packet count at the MAC layer (aFramesReceivedOK)? packets processed correctly by hardware? received by the driver? or maybe received by the stack? I tried to clarify the expectations, further clarifications from others are very welcome. The part hardest to untangle is rx_over_errors vs rx_fifo_errors vs rx_missed_errors. After much deliberation I concluded that for modern HW only two of the counters will make sense. The distinction between internal FIFO overflow and packets dropped due to back-pressure from the host is likely too implementation (driver and device) specific to expose in the standard stats. Now - which two of those counters we select to use is anyone's pick: sysfs documentation suggests rx_over_errors counts packets which did not fit into buffers due to MTU being too small, which I reused. There don't seem to be many modern drivers using it (well, CAN drivers seem to love this statistic). Of the remaining two I picked rx_missed_errors to report device drops. bnxt reports it and it's folded into "drop"s in procfs (while rx_fifo_errors is an error, and modern devices usually receive the frame OK, they just can't admit it into the pipeline). Of the drivers I looked at only AMD Lance-like and NS8390-like use all three of these counters. rx_missed_errors counts missed frames, rx_over_errors counts overflow events, and rx_fifo_errors counts frames which were truncated because they didn't fit into buffers. This suggests that rx_fifo_errors may be the correct stat for truncated packets, but I'd think a FIFO stat counting truncated packets would be very confusing to a modern reader. v2: - add driver developer notes about ethtool stat count and reset - replace Ethernet with IEEE 802.3 to better indicate source of attrs - mention byte counters don't count FCS - clarify RX counter is from device to host - drop "sightly" from sysfs paragraph - add examples of ethtool stats - s/incoming/received/ s/incoming/transmitted/ Signed-off-by: -
Wang Hai authored
rxrpc_min_rtt_wlen is never used after it was introduced. So better to remove it. Reported-by:
-
Jakub Kicinski authored
Edward Cree says: ==================== sfc: ethtool for EF100 and related improvements This series adds the ethtool support to the EF100 driver that was held back from the original submission as the lack of phy_ops caused issues. Patch #2, removing the phy_op indirection, deals with this. There are a lot of checkpatch warnings / xmastree violations but they're all in pure code movement so I've left the code as it is. While patch #1 is technically a fix and possibly could go to 'net', I've put it in this series since it only becomes triggerable with the added 'ethtool --reset' support. ==================== Signed-off-by: -
Edward Cree authored
Christoph says[1] that dma_set_mask_and_coherent() is smart enough to truncate the mask itself if it's too long. So we can get rid of our "lop off one bit and retry" loop in efx_init_io(). [1]: https://www.spinics.net/lists/netdev/msg677266.htmlSigned-off-by:
-
Edward Cree authored
Per-module versions for in-tree drivers are deprecated. Signed-off-by:
-
Edward Cree authored
If the reported PHY capabilities do not include a given FEC mode, don't attempt to select that FEC mode anyway. If the user tries to set a mode through ethtool that is not supported, return an error. The _REQUESTED bits don't appear in the supported caps, but are implied by the corresponding FEC bits. Signed-off-by:
-
Edward Cree authored
Mostly just calls to existing common functions. Signed-off-by:
-
Edward Cree authored
Originally there were several implementations of PHY operations for the several different PHYs used on Falcon boards. But Falcon is now in a separate driver, and all sfc NICs since then have had MCDI-managed PHYs. Thus, there is no need to indirect through function pointers in efx->phy_op; we can simply call the efx_mcdi_phy_* functions directly. This also hooks up these functions for EF100, which was previously using the dummy_phy_ops. Signed-off-by:
-
Edward Cree authored
dev_close(), by way of ef100_net_stop(), already brings down the filter table, so there's no need to do it again (which just causes lots of WARN_ONs). Similarly, don't bring it up ourselves, as dev_open() -> ef100_net_open() will do it, and will fail if it's already been brought up. Fixes: a9dc3d56 ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by:
-
