- 26 Jul, 2018 22 commits
-
-
Doron Roberts-Kedes authored
The zerocopy path ultimately calls iov_iter_get_pages, which defines the step function for ITER_KVECs as simply, return -EFAULT. Taking the non-zerocopy path for ITER_KVECs avoids the unnecessary fallback. See https://lore.kernel.org/lkml/20150401023311.GL29656@ZenIV.linux.org.uk/T/#u for a discussion of why zerocopy for vmalloc data is not a good idea. Discovered while testing NBD traffic encrypted with ktls. Fixes: c46234eb ("tls: RX path for ktls") Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
Code at line 1850 is unreachable. Fix this by removing the break statement above it, so the code for case RTM_GETCHAIN can be properly executed. Addresses-Coverity-ID: 1472050 ("Structurally dead code") Fixes: 32a4f5ec ("net: sched: introduce chain object to uapi") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guillaume Nault authored
The tunnel reception hook is only used by l2tp_ppp for skipping PPP framing bytes. This is a session specific operation, but once a PPP session sets ->recv_payload_hook on its tunnel, all frames received by the tunnel will enter pppol2tp_recv_payload_hook(), including those targeted at Ethernet sessions (an L2TPv3 tunnel can multiplex PPP and Ethernet sessions). So this mechanism is wrong, and uselessly complex. Let's just move this functionality to the pppol2tp rx handler and drop ->recv_payload_hook. Signed-off-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
when tipc_own_id failed to obtain node identity,dev_put should be call before return -EINVAL. Fixes: 682cd3cf ("tipc: confgiure and apply UDP bearer MTU on running links") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vakul Garg authored
Removed checks against non-NULL before calling kfree_skb() and crypto_free_aead(). These functions are safe to be called with NULL as an argument. Signed-off-by: Vakul Garg <vakul.garg@nxp.com> Acked-by: Dave Watson <davejwatson@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinicius Costa Gomes authored
This will allow to install a child qdisc under cbs. The main use case is to install ETF (Earliest TxTime First) qdisc under cbs, so there's another level of control for time-sensitive traffic. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Fixes the following sparse warning: drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:73:20: warning: symbol 'hns_ae_get_handle' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:332:6: warning: symbol 'hns_ae_stop' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:360:6: warning: symbol 'hns_ae_toggle_ring_irq' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:580:6: warning: symbol 'hns_ae_update_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:663:6: warning: symbol 'hns_ae_get_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:695:6: warning: symbol 'hns_ae_get_strings' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:728:5: warning: symbol 'hns_ae_get_sset_count' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:774:6: warning: symbol 'hns_ae_update_led_status' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:786:5: warning: symbol 'hns_ae_cpld_set_led_id' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:798:6: warning: symbol 'hns_ae_get_regs' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:823:5: warning: symbol 'hns_ae_get_regs_len' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c:342:6: warning: symbol 'hns_gmac_update_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:934:12: warning: symbol 'hns_mac_get_vaddr' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:953:5: warning: symbol 'hns_mac_get_cfg' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:343:6: warning: symbol 'hns_dsaf_srst_chns' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:366:1: warning: symbol 'hns_dsaf_srst_chns_acpi' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:373:6: warning: symbol 'hns_dsaf_roce_srst' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:387:6: warning: symbol 'hns_dsaf_roce_srst_acpi' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:571:5: warning: symbol 'hns_mac_get_sfp_prsnt' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c:589:5: warning: symbol 'hns_mac_get_sfp_prsnt_acpi' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:31:12: warning: symbol 'g_dsaf_mode_match' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:45:5: warning: symbol 'hns_dsaf_get_cfg' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:962:6: warning: symbol 'hns_dsaf_tcam_addr_get' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:2087:6: warning: symbol 'hns_dsaf_port_work_rate_cfg' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:2837:5: warning: symbol 'hns_dsaf_roce_reset' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c:76:5: warning: symbol 'hns_ppe_common_get_cfg' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c:107:6: warning: symbol 'hns_ppe_common_free_cfg' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c:340:6: warning: symbol 'hns_ppe_uninit_ex' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c:708:5: warning: symbol 'hns_rcb_get_ring_num' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c:744:14: warning: symbol 'hns_rcb_common_get_vaddr' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c:314:6: warning: symbol 'hns_xgmac_update_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_enet.c:1303:6: warning: symbol 'hns_nic_update_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_enet.c:1585:6: warning: symbol 'hns_nic_poll_controller' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_enet.c:1938:6: warning: symbol 'hns_set_multicast_list' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_enet.c:1960:6: warning: symbol 'hns_nic_set_rx_mode' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:661:6: warning: symbol 'hns_get_ringparam' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:811:6: warning: symbol 'hns_get_channels' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:828:6: warning: symbol 'hns_get_ethtool_stats' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:886:6: warning: symbol 'hns_get_strings' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:976:5: warning: symbol 'hns_get_sset_count' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:1010:5: warning: symbol 'hns_phy_led_set' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:1032:5: warning: symbol 'hns_set_phys_id' was not declared. Should it be static? drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:1106:6: warning: symbol 'hns_get_regs' was not declared. Should it be static? Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anders Roxell authored
Add the tls binary to .gitignore Fixes: 7f657d5b ("selftests: tls: add selftests for TLS sockets") Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
Currently, code at label *out* is unreachable. Fix this by updating variable *ret* with -EINVAL, so the jump to *out* can be properly executed instead of directly returning from function. Addresses-Coverity-ID: 1472059 ("Structurally dead code") Fixes: 1e2b44e7 ("rds: Enable RDS IPv6 support") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anders Roxell authored
Build error, implicit declaration of function __inet6_ehashfn shows up When RDS is enabled but not IPV6. net/rds/connection.c: In function ‘rds_conn_bucket’: net/rds/connection.c:67:9: error: implicit declaration of function ‘__inet6_ehashfn’; did you mean ‘__inet_ehashfn’? [-Werror=implicit-function-declaration] hash = __inet6_ehashfn(lhash, 0, fhash, 0, rds_hash_secret); ^~~~~~~~~~~~~~~ __inet_ehashfn Current code adds IPV6 as a depends on in config RDS. Fixes: eee2fa6a ("rds: Changing IP address internal representation to struct in6_addr") Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ursula Braun says: ==================== net/smc: patches 2018-07-25 here are 4 more patches for SMC: The first one is just a small code cleanup in preparation for patch 2. Patch 2 switches to the use of the vlan-gid for VLAN traffic. Patch 3 improves diagnosis when creating SMC connections. Patch 4 improves synchronization between local and remote link groups. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Karsten Graul authored
Send an orderly DELETE LINK request before termination of a link group, add support for client triggered DELETE LINK processing. And send a disorderly DELETE LINK before module is unloaded. Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Karsten Graul authored
Remember the fallback reason code and the peer diagnosis code for smc sockets, and provide them in smc_diag.c to the netlink interface. And add more detailed reason codes. Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
SMC code uses the base gid for VLAN traffic. The gids exchanged in the CLC handshake and the gid index used for the QP have to switch from the base gid to the appropriate vlan gid. When searching for a matching IB device port for a certain vlan device, it does not make sense to return an IB device port, which is not enabled for the used vlan_id. Add another check whether a vlan gid exists for a certain IB device port. Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
Link confirmation will always be sent across the new link being confirmed. This allows to shrink the parameter list. No functional change. Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: protect from theoretical size overflows and SR-IOV errors This small set changes the handling of pci_sriov_set_totalvfs() errors. nfp is the only driver which fails probe on pci_sriov_set_totalvfs() errors. It turns out some BIOS configurations may break SR-IOV and users who don't use that feature should not suffer. Remaining patches makes sure we use overflow-safe function for ring allocation, even though ring sizes are limited. It won't hurt and we can also enable fallback to vmalloc() if memory is tight while at it. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Use array_size() and store the size as full size_t to protect from theoretical size overflow when handling HW descriptor rings. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Commit 7f1c684a ("nfp: setup xdp_rxq_info") mixed the cache cold and cache hot data in the nfp_net_rx_ring structure (ignoring the feedback), to try to fit the structure into 2 cache lines after struct xdp_rxq_info was added. Now that we are about to add a new field the structure will grow back to 3 cache lines, so order the members correctly. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Use kvcalloc() instead of tmp variable + kzalloc() when allocating SW buffer information to allow falling back to vmalloc and to protect from theoretical integer overflow. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
On machines with buggy ACPI tables or when SR-IOV is already enabled we may not be able to set the SR-IOV VF limit in sysfs, it's not fatal because the limit is imposed by the driver anyway. Only the sysfs 'sriov_totalvfs' attribute will be too high. Print an error to inform user about the failure but allow probe to continue. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
The dma_mapping_error() returns true or false, but we want to return -ENOMEM if there was an error. Fixes: 174fd259 ("amd-xgbe: Implement split header receive support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2018 18 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Introduce algorithmic TCAM support The Spectrum-2 ASIC uses an algorithmic TCAM (A-TCAM) where multiple exact matches lookups are performed instead of a single lookup as with standard circuit TCAM (C-TCAM) memory. This allows for higher scale and reduced power consumption. The lookups are performed by masking a packet using different masks (e.g., {dst_ip/24, ethtype}) defined for the region and looking for an exact match. Eventually, the rule with the highest priority will be picked. Since the number of masks per-region is limited, the ASIC includes a C-TCAM that can be used as a spill area for rules that do not fit into the A-TCAM. The driver currently uses a C-TCAM only mode which is similar to Spectrum-1. However, this mode severely limits both the number of supported ACL rules and the performance of the ACL lookup. This patch set introduces initial support for the A-TCAM mode where the C-TCAM is only used for rule spillage. The first five patches add the registers and ASIC resources needed in order to make use of the A-TCAM. Next three patches are the "meat" and add the eRP core which is used to manage the masks used by each ACL region. The individual commit messages are lengthy and aim to thoroughly explain the subject. The next seven patches perform small adjustments in the code and the related data structures and are meant to prepare the code base to the introduction of the A-TCAM in the last two patches. Various A-TCAM optimization will be the focus of follow-up patch sets: * Pruning - Used to reduce the number of lookups. Each rule will include a prune vector that indicates which masks should not be considered for further lookups as they cannot result in a higher priority match * Bloom filter - Used to reduce the number of lookups. Before performing a lookup with a given mask the ASIC will consult a bloom filter (managed by the driver) that indicates whether a match might exist using the considered mask * Masks aggregation - Used to increase scale and reduce lookups. Masks that only differ by up to eight consecutive bits (delta bits) can be aggregated into a single mask. The delta bits then become a part of the rule's key. For example, dst_ip/16 and dst_ip/17 can be represented as dst_ip/16 with a delta bit of one. Rules using the aggregated mask then specify whether the 17-th bit should be masked or not and its value ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Now that all the pieces are in place we can start using the A-TCAM instead of only using the C-TCAM. This allows for much higher scale and better performance (to be improved further by follow-up patch sets). Perform the integration with the A-TCAM and the eRP core by reverting the changes introduced by "mlxsw: spectrum_acl: Enable C-TCAM only mode in eRP core" and add calls from the C-TCAM code into the eRP core. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Implement rule insertion and deletion into the A-TCAM before we flip the driver to start using the A-TCAM. Rule insertion into the A-TCAM is very similar to C-TCAM, but there are subtle differences between regions of different sizes (i.e., different number of key blocks). Specifically, as explained in "mlxsw: spectrum_acl: Allow encoding a partial key", in 12 key blocks regions a rule is split into two and the two halves of the rule are linked using a "large entry key ID". Such differences are abstracted away by using different region operations per region type. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When A-TCAM will be used together with C-TCAM, the C-TCAM code will need to call into the eRP core in order to get an eRP for an inserted entry. The eRP core takes an A-TCAM region as one of its arguments, so pass the C-TCAM region to the insertion function which will later allow us to derive the A-TCAM region, given it contains the C-TCAM one. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Before we start using the A-TCAM we need to make sure the region is properly initialized. This includes the setting of its type (which affects the size of its eRP table, for example) and its registration with the eRP core. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Each TCAM region currently uses its own resources and there is no sharing between the different regions. This is going to change with A-TCAM as each region will need to allocate an eRP table from the global eRP tables array. Make the global TCAM resources available to each region by passing the TCAM private data to the region initialization routine. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In Spectrum-2 the C-TCAM is only used for rules that can't fit in the A-TCAM due to a limited number of masks per A-TCAM region. In addition, rules inserted into the C-TCAM may affect rules residing in the A-TCAM, by clearing their C-TCAM prune bit. The two regions are thus closely related and can be thought of as if the C-TCAM region is encapsulated in the A-TCAM one. Change the data structures to reflect that before introducing A-TCAM support and make C-TCAM region initialization part of the A-TCAM region initialization sequence. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Initialize the A-TCAM as part of the driver's initialization routine. Specifically, initialize the eRP tables so that A-TCAM regions will be able to perform allocations of eRP tables upon rule insertion in subsequent patches. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When working with 12 key blocks in the A-TCAM, rules are split into two records, which constitute two lookups. The two records are linked using a "large entry key ID". The ID is assigned to key blocks 6 to 11 and resolved during the first lookup. The second lookup is performed using the ID and the remaining key blocks. Allow encoding a partial key so that it can be later used to check if an ID can be reused. This is done by adding two arguments to the existing encode function that specify the range of the block indexes we would like to encode. The key and mask arguments become optional, as we will not need to encode both of them all the time. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In a similar fashion to Spectrum-1's region struct, Spectrum-2's struct needs to store a pointer to the common region struct. The pointer will be used in follow-up patches that implement rules insertion and deletion. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The number of eRPs that can be used by a single A-TCAM region is limited to 16. When more eRPs are needed, an ordinary circuit TCAM (C-TCAM) can be used to hold the extra eRPs. Unlike the A-TCAM, only a single (last) lookup is performed in the C-TCAM and not a lookup per-eRP. However, modeling the C-TCAM as extra eRPs will allow us to easily introduce support for pruning in a follow-up patch set and is also logically correct. The following diagram depicts the relation between both TCAMs: C-TCAM +-------------------+ +--------------------+ +-----------+ | | | | | | | eRP #1 (A-TCAM) +----> ... +----+ eRP #16 (A-TCAM) +----+ eRP #17 | | | | | | ... | +-------------------+ +--------------------+ | eRP #N | | | +-----------+ Lookup order is from left to right. Extend the eRP core APIs with a C-TCAM parameter which indicates whether the requested eRP is to be used with the C-TCAM or not. Since the C-TCAM is only meant to absorb rules that can't fit in the A-TCAM due to exceeded number of eRPs or key collision, an error is returned when a C-TCAM eRP needs to be created when the eRP state machine is in its initial state (i.e., 'no masks'). This should only happen in the face of very unlikely errors when trying to push rules into the A-TCAM. In order not to perform unnecessary lookups, the eRP core will only enable a C-TCAM lookup for a given region if it knows there are C-TCAM eRPs present. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Currently, no calls are performed into the eRP core, but in order to make review easier we would like to gradually add these calls. Have the eRP core initialize a region's master mask to all ones and allow it to use an empty eRP table. This directs the lookup to the C-TCAM and allows the C-TCAM only mode to continue working. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When rules are inserted into the A-TCAM they are associated with a mask, which is part of the lookup key: { masked key, mask ID, region ID }. These masks are called rule patterns (RP) and the aggregation of several masks into one (to be introduced in follow-up patch sets) is called an extended RP (eRP). When a packet undergoes a lookup in an ACL region it is masked by the current set of eRPs used by the region, looking for an exact match. Eventually, the rule with the highest priority is picked. These eRPs are stored in several global banks to allow for lookup to occur using several eRPs simultaneously. At first, an ACL region will only require a single mask - upon the insertion of the first rule. In this case, the region can use the "master RP" which is composed by OR-ing all the masks used by the region. This mask is a property of the region and thus there is no need to use the above mentioned banks. At some point, a second mask will be needed. In this case, the region will need to allocate an eRP table from the above mentioned banks and insert its masks there. >From now on, upon lookup, the eRP table used by the region will be fetched from the eRP banks - using {eRP bank, Index within the bank} - and the eRPs present in the table will be used to mask the packet. Note that masks with consecutive indexes are inserted into consecutive banks. When rules are deleted and a region only needs a single mask once again it can free its eRP table and use the master RP. The above logic is implemented in the eRP core and represented using the following state machine: +------------+ create mask - as master RP +---------------+ | +--------------------------------> | | no masks | | single mask | | <--------------------------------+ | +------------+ delete mask +-----+--^------+ | | | | create mask - | | delete mask - create mask transition to use eRP | | transition to +--------+ table | | use master RP | | | | | | | | +----v--------+----+ create mask +----v--+-----+ | <-------------------------------+ | | multiple masks | | two masks | | +-------------------------------> | +------------------+ delete mask - if two +-------------+ remaining The code that actually configures rules in the A-TCAM will interface with the eRP core by getting or putting an eRP based on the required mask used by the rule. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Add the following resources to be used by A-TCAM code: * Maximum number of eRP banks * Maximum size of eRP bank * Number of eRP entries required for a 2/4/8/12 key blocks mask Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Add a resource to make sure we do not exceed the maximum number of supported large key IDs in a region. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The register is used to add and delete eRPs from the eRP table. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The register is used to configure rules in the A-TCAM. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Before introducing A-TCAM support we need to make sure all the necessary fields are configurable and not hard coded to values that worked for the C-TCAM only use case. This includes - for example - the ability to configure the eRP table used by the TCAM region. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-