- 15 Nov, 2018 22 commits
-
-
Jiri Pirko authored
Allow ERP sharing for multiple mask. Do it by properly implementing delta_create() objagg object. Use the computed delta info for inserting rules in A-TCAM. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Later on the same code is going to be needed for deltas as well. So push the procedures related to increment and decrement of num_ctcam_erps into a separate helpers. Signed-off-by:
-
Jiri Pirko authored
Since two remaining users of mlxsw_afk_encode() do not specify block ranges to work on, remove the args. Also, key/mask is always non-NULL now, so skip the checks. Signed-off-by:
-
Jiri Pirko authored
No need to do key encoding again in mlxsw_sp_acl_atcam_12kb_lkey_id_get(). Instead of that, introduce a new helper that would just clear unused blocks. Signed-off-by:
-
Jiri Pirko authored
Change order so it is aligned with the usual case where the "write_to" buffer comes as the first arg. Signed-off-by:
-
Jiri Pirko authored
The device requires that the master mask of each region will be composed from a logical OR between all the unmasked bits in the region. Currently, this is just a logical OR between all the eRPs used in the region, but the next patch is going to introduce delta bits support which need to be taken into account as well. Since the eRP does not include the delta bits, pass the key pointer to mlxsw_sp_acl_erp_master_mask_set/clear instead. Convert key->mask to the bitmap on fly. Signed-off-by:
-
Jiri Pirko authored
Currently the ERPs are tracked internally in a hashtable. Benefit from the newly introduced objagg library and use it to track ERPs. At this point, there is no nesting of objects done, as the delta_create callback always returns -EOPNOTSUPP. On the way, add "mask" into ERP mask get and set functions and struct names. Signed-off-by:
-
Jiri Pirko authored
This lib tracks objects which could be of two types: 1) root object 2) nested object - with a "delta" which differentiates it from the associated root object The objects are tracked by a hashtable and reference-counted. User is responsible of implementing callbacks to create/destroy root entity related to each root object and callback to create/destroy nested object delta. Signed-off-by: -
Jiri Pirko authored
In order for this to behave as required with delta bits, change the mask for rule with handle 103. Signed-off-by:
-
Jiri Pirko authored
In order for this to behave as required with delta bits, change the mask for rule with handle 103. Signed-off-by:
-
Cong Wang authored
__tcp_checksum_complete() is 100% same with __skb_checksum_complete() and there is no other caller except tcp_checksum_complete(). So, just use __skb_checksum_complete() there. Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Amritha Nambiar authored
Added support in tc flower for filtering based on port ranges. Example: 1. Match on a port range: ------------------------- $ tc filter add dev enp4s0 protocol ip parent ffff:\ prio 1 flower ip_proto tcp dst_port range 20-30 skip_hw\ action drop $ tc -s filter show dev enp4s0 parent ffff: filter protocol ip pref 1 flower chain 0 filter protocol ip pref 1 flower chain 0 handle 0x1 eth_type ipv4 ip_proto tcp dst_port range 20-30 skip_hw not_in_hw action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 85 sec used 3 sec Action statistics: Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0) backlog 0b 0p requeues 0 2. Match on IP address and port range: -------------------------------------- $ tc filter add dev enp4s0 protocol ip parent ffff:\ prio 1 flower dst_ip 192.168.1.1 ip_proto tcp dst_port range 100-200\ skip_hw action drop $ tc -s filter show dev enp4s0 parent ffff: filter protocol ip pref 1 flower chain 0 handle 0x2 eth_type ipv4 ip_proto tcp dst_ip 192.168.1.1 dst_port range 100-200 skip_hw not_in_hw action order 1: gact action drop random type none pass val 0 index 2 ref 1 bind 1 installed 58 sec used 2 sec Action statistics: Sent 920 bytes 20 pkt (dropped 20, overlimits 0 requeues 0) backlog 0b 0p requeues 0 v4: 1. Added condition before setting port key. 2. Organized setting and dumping port range keys into functions and added validation of input range. v3: 1. Moved new fields in UAPI enum to the end of enum. 2. Removed couple of empty lines. v2: Addressed Jiri's comments: 1. Added separate functions for dst and src comparisons. 2. Removed endpoint enum. 3. Added new bit TCA_FLOWER_FLAGS_RANGE to decide normal/range lookup. 4. Cleaned up fl_lookup function. Signed-off-by:Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by:
-
Cong Wang authored
Currently netdev_rx_csum_fault() only shows a device name, we need more information about the skb for debugging csum failures. Sample output: ens3: hw csum failure dev features: 0x0000000000014b89 skb len=84 data_len=0 pkt_type=0 gso_size=0 gso_type=0 nr_frags=0 ip_summed=0 csum=0 csum_complete_sw=0 csum_valid=0 csum_level=0 Note, I use pr_err() just to be consistent with the existing one. Signed-off-by:
-
Andrew Lunn authored
We already have a workaround for a couple of switches whose internal PHYs only have the Marvel OUI, but no model number. We detect such PHYs and give them the 6390 ID as the model number. However the mv88e6161 has two SERDES interfaces in the same address range as its internal PHYs. These suffer from the same problem, the Marvell OUI, but no model number. As a result, these SERDES interfaces were getting the same PHY ID as the mv88e6390, even though they are not PHYs, and the Marvell PHY driver was trying to drive them. Add a special case to stop this from happen. Reported-by:
Chris Healy <Chris.Healy@zii.aero> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2018-11-13 This series contains updates to the ice driver only. Brett cleans up debug print messages by removing useless or duplicate messages, and make sure we assign the hardware head pointer to head instead of the software head pointer. Resolved an issue when disabling SRIOV we were trying to stop queues multiple times, so make sure we disable SRIOV before stopping transmit and receive queues for VF. Tony fixes a potential NULL pointer dereference during a VF reset. Anirudh resolves an issue where we were releasing the VSI before removing the VSI scheduler node, which was resulting in an error "Failed to set LAN Tx queue context, error: -1". Also fixed the guaranteed number of VSIs available and used by discovering the device capabilities to determine the 'guar_num_vsi' per function, rather than always using the theoretical max number of VSIs every time. Dave avoids a deadlock by nesting RTNL locking, so added a boolean to determine if the RTNL lock is already held. Lev fixes bad mask values which would break compilation. Piotr increases the receive queue disable timeout since it can take additional time to finish all pending queue requests. Usha resolves an issue of VLAN priority tagged traffic not appearing on all traffic classes, which was causing ETS bandwidth shaping to not work as expected. Henry fixes the reset path to cleanup the old scheduler tree before rebuilding it. Md Fahad removes a unnecessary check which was causing a driver load error on platforms with more than 128 cores. ==================== Signed-off-by: -
David S. Miller authored
Salil Mehta says: ==================== net: hns3: Add support of hardware GRO to HNS3 Driver This patch-set adds support of hardware assisted GRO feature to HNS3 driver on Rev B(=0x21) platform. Current hardware only supports TCP/IPv{4|6} flows. Change Log: V1->V2: 1. Remove redundant print reported by Leon Romanovsky. Link: https://lkml.org/lkml/2018/11/13/715 ==================== Signed-off-by: -
Peng Li authored
When HW GRO enable, protocol stack will not do GRO again, driver should add gro param to the skb for the protocol stack.. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Peng Li authored
MAX_SKB_FRAGS in protocol stack is defined as: MAX_SKB_FRAGS is 17 when PAGE_SIZE is 4K. If HW enable GRO, it may merge small packets and the rx buffer may be more than MAX_SKB_FRAGS. So driver will add skb chain when RX buffer num. more than MAX_SKB_FRAGS. Signed-off-by:
-
Peng Li authored
This patch adds support of ethtool -K to enable/disable hardware GRO in HNS3 PF/VF driver. Signed-off-by:
-
Peng Li authored
The "FE bit" in the description means the last description for a packets. When HW GRO enable, HW write data to ring every packet/buffer, there is greater probability that driver handle with the describtion but HW still not set the "FE bit". When drier handle the packet and HW still not set "FE bit", driver stores skb and bd_num in rx ring, and continue to use the skb and bd_num in next napi. Signed-off-by:
-
Peng Li authored
HNS3 hardware Revision B(=0x21) supports Hardware GRO feature. This patch enables this feature in the HNS3 PF/VF driver. Signed-off-by:
-
Heiner Kallweit authored
Move IRQ configuration for IP101A/G from config_init to config_intr callback. Reasons: 1. This allows phylib to disable interrupts if needed. 2. Icplus was the only driver supporting interrupts w/o defining a config_intr callback. Now we can add a phylib plausibility check disabling interrupt mode if one of the two irq-related callbacks isn't defined. I don't own hardware with this PHY, and the change is based on the datasheet for IP101A LF (which is supposed to be register-compatible with IP101A/G). Change is compile-tested only. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- 14 Nov, 2018 18 commits
-
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: abm: track all Qdiscs Our Qdisc offload so far has been very simplistic. We held and array of marking thresholds and statistics sized to the number of PF queues. This was sufficient since the only configuration we supported was single layer of RED Qdiscs (on top of MQ or not, but MQ isn't really about queuing). As we move to add more Qdiscs it's time to actually try to track the full Qdisc hierarchy. This allows us to make sure our offloaded configuration reflects the SW path better. We add graft notifications to MQ and RED (PRIO already sends them) to allow drivers offloading those to learn how Qdiscs are linked. MQ graft gives us the obvious advantage of being able to track when Qdiscs are shared or moved. It seems unlikely HW would offload RED's child Qdiscs but since the behaviour would change based on linked child we should stop offloading REDs with modified child. RED will also handle the child differently during reconfig when limit parameter is set - so we have to inform the drivers about the limit, and have them reset the child state when appropriate. The NFP driver will now allocate a structure to track each Qdisc and link it to its children. We will also maintain a shadow copy of threshold settings - to save device writes and make it easier to apply defaults when config is re-evaluated. ==================== Signed-off-by: -
Jakub Kicinski authored
In preparation of handling more Qdisc types switch to a different offload strategy. We have now recreated the Qdisc hierarchy in the driver. Every time the hierarchy changes parse it, and update the configuration of the HW accordingly. While at it drop the support of pretending that we can instantiate a single queue on a multi-queue device in HW/FW. MQ is now required, and each queue will have its own instance of RED. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
Use the new driver Qdisc structure to keep track of parameters of RED Qdiscs. This way as the Qdisc moves around in the hierarchy we will be able to configure the HW appropriately. Signed-off-by:
-
Jakub Kicinski authored
RED qdisc will replace its child Qdisc with a new FIFO queue if it is reconfigured and the limit parameter is not 0. This means that when it's created with limit of 0 it will have no FIFO, and all packets will be dropped. If it's changed and limit is specified it will loose its existing child (implicit graft). Make sure we mark RED Qdisc child as NFP_QDISC_UNTRACKED if its not the expected FIFO. nfp_abm_qdisc_replace() will return 1 if Qdisc already existed. Signed-off-by:
-
Jakub Kicinski authored
RED qdisc's limit parameter changes the behaviour of the qdisc, for instance if it's set to 0 qdisc will drop all the packets. When replace operation happens and parameter is set to non-0 a new fifo qdisc will be instantiated and replace the old child qdisc which will be destroyed. Drivers need to know the parameter, even if they don't impose the actual limit to be able to reliably reconstruct the Qdisc hierarchy. Signed-off-by:
-
Jakub Kicinski authored
Using graft notifications recreate in the driver the full Qdisc hierarchy. Keep track of how many times each Qdisc is attached to the hierarchy to make sure we don't offload Qdiscs which are attached multiple times (device queues can't be shared). For graft events of Qdiscs we don't know exist make the child as invalid/untracked. Note that MQ Qdisc doesn't send destruction events reliably when device is dismantled, so we need to manually clean out the children otherwise we'd think Qdiscs which are still in use are getting freed. Signed-off-by:
-
Jakub Kicinski authored
Drivers offloading Qdiscs should have reasonable certainty the offloaded behaviour matches the SW path. This is impossible if the driver does not know about all Qdiscs or when Qdiscs move and are reused. Send a graft notification from MQ. Signed-off-by:
-
Jakub Kicinski authored
Drivers offloading Qdiscs should have reasonable certainty the offloaded behaviour matches the SW path. This is impossible if the driver does not know about all Qdiscs or when Qdiscs move and are reused. Send a graft notification from RED. The drivers are expected to simply stop offloading the Qdisc, if a non-standard child is ever grafted onto it. Signed-off-by:
-
Jakub Kicinski authored
To keep track of Qdisc hierarchy allocate a table for children for each Qdisc. RED Qdisc can only have one child. Signed-off-by:
-
Jakub Kicinski authored
Keep track of which Qdisc is currently root. We need to implement TC_SETUP_ROOT_QDISC handling, and for completeness also clear the root Qdisc pointer when it's freed. TC_SETUP_ROOT_QDISC isn't always sent when device is dismantled. Remembering the root Qdisc will allow us to build the entire hierarchy in following patches. Signed-off-by:
-
Jakub Kicinski authored
Drivers are currently not notified when a Qdisc is grafted as root. This requires special casing Qdiscs added with parent = TC_H_ROOT in the driver. Also there is no notification sent to the driver when an existing Qdisc is grafted as root. Add this very simple notifications, drivers should now be able to track their Qdisc tree fully. Signed-off-by:
-
Jakub Kicinski authored
Allocate an object corresponding to any offloaded qdisc we are informed about by the kernel. Not only the qdiscs we have a chance of offloading. The count of created objects will be used to decide whether the ethtool TC offload can be disabled, since otherwise we may miss destroy commands. Signed-off-by:
-
Jakub Kicinski authored
Instead of writing the threshold out when Qdisc is configured and not remembering it move to a scheme where we remember all thresholds. When configuration changes parse the offloaded Qdiscs and set thresholds appropriately. This will help future extensions. Signed-off-by:
-
Jakub Kicinski authored
Rename qdiscs member to red_qdiscs. One of following patches will use the name qdiscs for tracking all qdisc types. Signed-off-by:
-
David S. Miller authored
Igor Russkikh says: ==================== net: aquantia: add rx-flow filter support In this patchset the rx-flow filters functionality and vlan filter offloads are implemented. The rules in NIC hardware have fixed order and priorities. To support this, the locations of filters from ethtool perspective are also fixed: * Locations 0 - 15 for VLAN ID filters * Locations 16 - 31 for L2 EtherType and PCP filters * Locations 32 - 39 for L3/L4 5-tuple filters (locations 32, 36 for IPv6) ==================== Signed-off-by: -
Dmitry Bogdanov authored
Since it uses the same NIC table as rx flow vlan filter therefore rx-flow vlan filter accepts only vlans that present on the interface in case of rx-vlan-filter is on. Signed-off-by:
Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
-
Dmitry Bogdanov authored
L2 EtherType filters allows to filter packet by EtherType field or both EtherType and User Priority (PCP) field of 802.1Q. UserPriority (vlan) parameter must be accompanied by mask 0x1FFF. That is to distinguish VLAN filter from L2 Ethertype filter with UserPriority since both User Priority and VLAN ID are passed in the same 'vlan' parameter. Example: To add a filter that directs IP4 packess of priority 3 to queue 3: ethtool -N <ethX> flow-type ether proto 0x800 vlan 0x600 m 0x1FFF \ action 3 loc 16 Signed-off-by:
-
Dmitry Bogdanov authored
The VLAN filter (VLAN id) is compared against 16 filters. VLAN id must be accompanied by mask 0xF000. That is to distinguish VLAN filter from L2 Ethertype filter with UserPriority since both User Priority and VLAN ID are passed in the same 'vlan' parameter. Flow type may be any as it is not matched for VLAN filter. Due to fixed order of the rules in the NIC, the location 0-15 are reserved for vlan filters. Example: To add a rule that directs packets from VLAN 2001 to queue 5: ethtool -N <ethX> flow-type ip4 vlan 2001 m 0xF000 action 5 loc 0 Signed-off-by:
-
