- 22 Feb, 2019 21 commits
-
-
Eli Britstein authored
When using the device packet encapsulation offload, the device calculates an entropy value, representing the inner packet headers. The entropy field is placed inside the outer packet headers. For UDP-type encapsulations, the entropy is placed in the source port field of the UDP header. For GRE-type encapsulations, the entropy is placed in the 8 LSB of the key field in the GRE header. If the device does not recognize the encapsulation type, the entropy is not placed in the packet. Entropy setting can be controlled using PCMR register. if encapsulation offload is not used force_entropy_cap should be set to 0x0. Entropy setting is enabled/disabled using entropy_calc, and could be additionally enabled/disabled for GRE encapsulation by entropy_gre_calc. As a pre-step to automatically control the tunnel entropy, introduce the entropy fields in the PCMR register with no functional change. Signed-off-by:
Eli Britstein <elibr@mellanox.com> Reviewed-by:
Oz Shlomo <ozsh@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
Currently changing a PCMR field is done by setting the field in a zeroed buffer, zeroing other unrelated fields. Fix this behaviour by modifying only the required field after first reading the current register values, as a pre-step towards using more fields in PCMR register. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: VLAN devices w/ filtering This patch series supports having VLAN devices on top of DSA/switch ports while the switch has VLAN filtering globally turned on (as is the case with Broadcom switches). Whether the switch does global or per-port VLAN filtering, having VLAN entries for these VLAN devices is beneficial. We take care of a few possibly problematic cases: - adding a VLAN device while there is an existing VLAN entry created by a VLAN aware bridge. The entire bridge's VLAN database and not just the specific bridge port is being checked to be safe and conserative - adding a bridge VLAN entry when there is an existing VLAN device created is also not possible because that would lead to the bridge being able to manipulate the VLAN device's VID/attributes under its feet - enslaving a VLAN device into a VLAN aware bridge since that duplicates functionality already offered by the VLAN aware bridge Here are the different test cases that were run to exercise this: ip addr flush dev gphy ip link add dev br0 type bridge echo 1 > /sys/class/net/br0/bridge/vlan_filtering ip link set dev gphy master br0 udhcpc -i br0 vconfig add rgmii_1 100 ifconfig rgmii_1.100 192.168.100.10 ping -c 2 192.168.100.1 vconfig add br0 42 bridge vlan add vid 42 dev gphy bridge vlan add vid 42 dev br0 self ifconfig br0.42 192.168.42.2 ping -c 2 192.168.42.1 ip link del rgmii_1.100 vconfig add rgmii_1 100 ifconfig rgmii_1.100 192.168.100.10 ping -c 2 192.168.100.1 echo 0 > /sys/class/net/br0/bridge/vlan_filtering ping -c 2 192.168.100.1 ip link del rgmii_1.100 echo 1 > /sys/class/net/br0/bridge/vlan_filtering vconfig add rgmii_1 100 brctl addif br0 rgmii_1 bridge vlan add vid 100 dev rgmii_1 vconfig rem rgmii_1.100 bridge vlan add vid 100 dev rgmii_1 vconfig add rgmii_1 100 bridge vlan del vid 100 dev rgmii_1 vconfig add rgmii_1 100 brctl addif br0 rgmii_1.100 ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
In order to properly support VLAN filtering being enabled/disabled on a bridge, while having other ports being non bridge port members, we need to support the ndo_vlan_rx_{add,kill}_vid callbacks in order to make sure the non-bridge ports can continue receiving VLAN tags, even when the switch is globally configured to do ingress/egress VID checking. Since we can call dsa_port_vlan_{add,del} with a bridge_dev pointer NULL, we now need to check that in these two functions. We specifically deal with two possibly problematic cases: - creating a bridge VLAN entry while there is an existing VLAN device claiming that same VID - creating a VLAN device while there is an existing bridge VLAN entry with that VID Those are both resolved with returning -EBUSY back to user-space. Signed-off-by:Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
VLAN devices on top of a DSA network device which is already part of a bridge and with said bridge being VLAN aware should not be allowed to be enslaved into that bridge. For one, this duplicates functionality offered by the VLAN aware bridge which supports tagged and untagged VLAN frames processing and it would make things needlessly complex to e.g.: propagate FDB/MDB accordingly. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/isdn/i4l/isdn_common.c: In function ‘isdn_wildmat’: drivers/isdn/i4l/isdn_common.c:173:5: warning: this statement may fall through [-Wimplicit-fallthrough=] p++; ~^~ drivers/isdn/i4l/isdn_common.c:174:3: note: here default: ^~~~~~~ CC [M] drivers/leds/leds-lp8788.o CC [M] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu10_smumgr.o drivers/isdn/i4l/isdn_common.c: In function ‘isdn_status_callback’: drivers/isdn/i4l/isdn_common.c:729:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (divert_if) ^ drivers/isdn/i4l/isdn_common.c:732:2: note: here default: ^~~~~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Andrew Lunn authored
Use the new PHY driver call to get the PHYs supported features. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> [hkallweit1@gmail.com: removed new config_init callback from patch] Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Florian Fainelli authored
A missing break keyword should have been added after adding support for PRE_BRIDGE_FLAGS. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 93700458 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS") Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== code optimizations & bugfixes for HNS3 driver This patchset includes bugfixes and code optimizations for the HNS3 ethernet controller driver. ==================== Signed-off-by: -
Huazhong Tan authored
According to the hardware's description, the driver should clear the command queue's registers when uloading VF driver. Otherwise, these existing value may lead the IMP get into a wrong state. Fixes: fedd0c15 ("net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Huazhong Tan authored
According to the hardware's description, the driver should clear the command queue's registers when uloading driver. Otherwise, these existing value may lead the IMP get into a wrong state. Also this patch adds hclge_cmd_uninit() to do the command queue uninitialization which includes clearing registers and freeing memory. Fixes: 68c0a5c7 ("net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support") Signed-off-by:
-
liuzhongzhu authored
Record the vlan tables that the VF sends to the chip. After the VF exception, the PF actively clears the VF to chip config. Signed-off-by:
liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by:
-
liuzhongzhu authored
Record the unicast and multicast tables that the VF sends to the chip. After the VF exception, the PF actively clears the VF to chip config. Signed-off-by:
-
Weihang Li authored
This patch modify print message of 6th bit of ppp mpf abnormal errors, there is a extra letter e in it. Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
-
Weihang Li authored
These bits are enabled now and have been test. Signed-off-by:
-
Weihang Li authored
The 3rd and 4th of PPU(RCB) PF Abnormal is RAS errors instead of MSI-X like other bits. This patch adds process of handling and logging this two bits. Otherwise, this patch modifies print message of 28th and 29th bit of PPU MPF Abnormal errors, which keep same with other errors now. Fixes: f69b10b3 ("net: hns3: handle hw errors of PPU(RCB)") Signed-off-by:
-
Weihang Li authored
This patch add information of specific bit in log to be consistent with other type of errors, so that we can know which memory of ssu has occurred a ecc ras errors. Signed-off-by:
-
Jian Shen authored
In original codes, for copper port which doesn't connect to phy, it always returns -EOPNOTSUPP when query port information. This patch fixes it by return the port information of MAC. Fixes: 5f373b15 ("net: hns3: Fix speed/duplex information loss problem when executing ethtool ethx cmd of VF") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
The link mode with bits has been up to more than 31 for some MAC and phy. Convert to using a linkmode bitmap, which can support all link modes. Signed-off-by:
-
Yonglong Liu authored
In hnae3_register_ae_dev(), ae_algo->ops is assigned to ae_dev->ops before check that ae_algo->ops is valid. And in hnae3_register_ae_algo(), missing check for ae_algo->ops. This patch fixes them. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
Yonglong Liu authored
These functions are exported, add pointer checking at the beginning can make them more safe. Signed-off-by:
-
- 21 Feb, 2019 19 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Support for shared buffers in Spectrum-2 Petr says: Spectrum-2 will be configured with a different set of pools than Spectrum-1, their sizes will be larger, and the individual quotas will be different as well. It is therefore necessary to make the shared buffer module aware of this dependence on chip type, and adjust the individual tables. In patch #1, introduce a structure for keeping per-chip immutable and default values. In patch #2, structures for keeping current values of SBPM and SBPR (pool configuration and port-pool quota) are allocated dynamically to support varying pool counts. In patches #3 to #7, uses of individual shared buffer configuration tables are migrated from global definitions to fields in struct mlxsw_sp_sb_vals, which was introduced above. Up until this point, the actual configuration is still the one suitable for Spectrum-1. In patch #8 Spectrum-2 configuration is added. In patch #9, port headroom configuration is changed to take into account current recommended value for a 100-Gbps port, and the split factor. In patch #10, requests for overlarge headroom are rejected. This avoids potential chip freeze should such overlarge requests be made. ==================== Signed-off-by: -
Petr Machata authored
cap_max_headroom_size holds maximum headroom size supported. Overstepping that limit might under certain conditions lead to ASIC freeze. Query and store the value, and add mlxsw_sp_sb_max_headroom_cells() for obtaining the stored value. In __mlxsw_sp_port_headroom_set(), reject requests where the total port buffer is larger than the advertised maximum. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
The recommendation for headroom size for 100Gbps port and 100m cable is 101.6KB, reduced accordingly for split ports. The closest higher number evenly divisible by cell size for both Spectrum-1 and Spectrum-2, and such that the number of cells can be further divided by maximum split factor of 4, is 102528 bytes, or 25632 bytes per lane. Update mlxsw_sp_port_pb_init() to compute the headroom taking into account this recommended per-lane value and number of lanes actually dedicated to a given port. Signed-off-by:
-
Petr Machata authored
Customize the tables related to shared buffer configuration to match the current recommendation for Spectrum-2 systems. Signed-off-by:
-
Petr Machata authored
The SBMM register configures the shared buffer quota for MC packets according to Switch-Priority. The default configuration depends on the chip type. Therefore keep the table and length in struct mlxsw_sp_sb_vals. Redirect the references from the global definitions to the fields. Signed-off-by:
-
Petr Machata authored
The SBCM register configures shared buffer quota according to port-priority resp. port-TC. The default configuration depends on the chip type. Therefore keep the tables and their lengths in struct mlxsw_sp_sb_vals. Redirect the references from the global definitions to the fields. Signed-off-by:
-
Petr Machata authored
The SBPR register configures shared buffer pools. The default configuration depends on the chip type. Therefore keep it in struct mlxsw_sp_sb_vals. Redirect the one reference from the global array to the field. Because the pool descriptor ID is implicit in the ordering of array members, both this array and the pool descriptor array have the same length. Therefore reuse mlxsw_sp_sb.pool_dess_len for the purpose of determining the length of SBPR array. Drop the now useless MLXSW_SP_SB_PRS_LEN. Signed-off-by:
-
Petr Machata authored
The SBPM register can be used to configure quotas for packets ingressing from a certain pool to a certain port, and egressing from a certain pool to a certain port. The default configuration depends on the chip type. Therefore keep it in struct mlxsw_sp_sb_vals. Redirect the one reference from the global array to the field. Because the pool descriptor ID is implicit in the ordering of array members, both this array and the pool descriptor array have the same length. Therefore reuse mlxsw_sp_sb.pool_dess_len for the purpose of determining the length of SBPM array. Drop the now useless MLXSW_SP_SB_PMS_LEN. Signed-off-by:
-
Petr Machata authored
Keep the table of pool descriptors and its length in struct mlxsw_sp_sb_vals so that it can be specialized per chip type. Redirect all users from the global definitions to the mlxsw_sp_sb fields. Give mlxsw_sp_pool_count() an extra mlxsw_sp parameter so that it can access the descriptor table. Drop the now unnecessary MLXSW_SP_SB_POOL_DESS_LEN. Signed-off-by:
-
Petr Machata authored
Spectrum-2 will be configured with a different set of pools than Spectrum-1. The size of prs and pms buffers will therefore depend on the chip type of the device. Therefore, instead of reserving an array directly in a structure definition, allocate the buffer in mlxsw_sp_sb_port{,s}_init(). Signed-off-by: -
Petr Machata authored
Spectrum-2 will be configured with a different shared buffer configuration than Spectrum-1. Therefore introduce a structure for keeping the chip-specific default and immutable configuration. Configuration mutable in runtime will still be kept in struct mlxsw_sp_sb. Signed-off-by:
-
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: Performance improvements in Multi-Queue Tested in XGMAC2 and GMAC5. ==================== Signed-off-by: -
Jose Abreu authored
TBU interrupt is a normal interrupt and can be used to trigger the cleaning of TX path. Lets check if it's active in DMA interrupt handler. While at it, refactor a little bit the function: - Don't check if RI is enabled because at function exit we will only clear the interrupts that are enabled so, no event will be missed. In my tests withe XGMAC2 this increased performance. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Jose Abreu authored
TBU interrupt is a normal interrupt and can be used to trigger the cleaning of TX path. Lets check if it's active in DMA interrupt handler. While at it, refactor a little bit the function: - Don't check if RI is enabled because at function exit we will only clear the interrupts that are enabled so, no event will be missed. In my tests with GMAC5 this increased performance. Signed-off-by:
-
Jose Abreu authored
Commit 8fce3331 introduced the concept of NAPI per-channel and independent cleaning of TX path. This is currently breaking performance in some cases. The scenario happens when all packets are being received in Queue 0 but the TX is performed in Queue != 0. Fix this by using different NAPI instances per each TX and RX queue, as suggested by Florian. Changes from v2: - Only force restart transmission if there are pending packets Changes from v1: - Pass entire ring size to TX clean path (Florian) Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: Get rid of switchdev_port_attr_get() This patch series splits the removal of the switchdev_ops that was proposed a few times before and first tackles the easy part which is the removal of the single call to switchdev_port_attr_get() within the bridge code. As suggestd by Ido, this patch series adds a SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS which is used in the same context as the caller of switchdev_port_attr_set(), so not deferred, and then the operation is carried out in deferred context with setting a support bridge port flag. Follow-up patches will do the switchdev_ops removal after introducing the proper helpers for the switchdev blocking notifier to work across stacked devices (unlike the previous submissions). David this does depend on Russell's "[PATCH net-next v5 0/3] net: dsa: mv88e6xxx: fix IPv6". Changes in v3: - rebased against net-next/master after Russell's IPv6 changes to DSA - ignore prepare/commit phase for PRE_BRIDGE_FLAGS since we don't want to trigger the WARN() in net/switchdev/switchdev.c in the commit phase Changes in v2: - differentiate callers not supporting switchdev_port_attr_set() from the driver not being able to support specific bridge flags - pass "mask" instead of "flags" for the PRE_BRIDGE_FLAGS check - skip prepare phase for PRE_BRIDGE_FLAGS - corrected documentation a bit more - tested bridge_vlan_aware.sh with veth/VRF ==================== Signed-off-by: -
Florian Fainelli authored
With the bridge no longer calling switchdev_port_attr_get() to obtain the supported bridge port flags from a driver but instead trying to set the bridge port flags directly and relying on driver to reject unsupported configurations, we can effectively get rid of switchdev_port_attr_get() entirely since this was the only place where it was called. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Florian Fainelli authored
Now that we have converted the bridge code and the drivers to check for bridge port(s) flags at the time we try to set them, there is no need for a get() -> set() sequence anymore and SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused. Reviewed-by:
-
Florian Fainelli authored
Now that all switchdev drivers have been converted to check the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS flags and report flags that they do not support accordingly, we can migrate the bridge code to try to set that attribute first, check the results and then do the actual setting. Signed-off-by:
-
