- 18 Mar, 2020 36 commits
-
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: vlan options: add support for tunnel mapping In order to bring the new vlan API on par with the old one and be able to completely migrate to the new one we need to support vlan tunnel mapping and statistics. This patch-set takes care of the former by making it a vlan option. There are two notable issues to deal with: - vlan range to tunnel range mapping * The tunnel ids are globally unique for the vlan code and a vlan can be mapped to one tunnel, so the old API took care of ranges by taking the starting tunnel id value and incrementally mapping vlan id(i) -> tunnel id(i). This set takes the same approach and uses one new attribute - BRIDGE_VLANDB_ENTRY_TUNNEL_ID. If used with a vlan range then it's the starting tunnel id to map. - tunnel mapping removal * Since there are no reserved/special tunnel ids defined, we can't encode mapping removal within the new attribute, in order to be able to remove a mapping we add a vlan flag which makes the new tunnel option remove the mapping The rest is pretty straight-forward, in fact we directly re-use the old code for manipulating tunnels by just mapping the command (set/del). In order to be able to keep detecting vlan ranges we check that the current vlan has a tunnel and it's extending the current vlan range end's tunnel id. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
This patch adds support for manipulating vlan/tunnel mappings. The tunnel ids are globally unique and are one per-vlan. There were two trickier issues - first in order to support vlan ranges we have to compute the current tunnel id in the following way: - base tunnel id (attr) + current vlan id - starting vlan id This is in line how the old API does vlan/tunnel mapping with ranges. We already have the vlan range present, so it's redundant to add another attribute for the tunnel range end. It's simply base tunnel id + vlan range. And second to support removing mappings we need an out-of-band way to tell the option manipulating function because there are no special/reserved tunnel id values, so we use a vlan flag to denote the operation is tunnel mapping removal. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Add a new option - BRIDGE_VLANDB_ENTRY_TUNNEL_ID which is used to dump the tunnel id mapping. Since they're unique per vlan they can enter a vlan range if they're consecutive, thus we can calculate the tunnel id range map simply as: vlan range end id - vlan range start id. The starting point is the tunnel id in BRIDGE_VLANDB_ENTRY_TUNNEL_ID. This is similar to how the tunnel entries can be created in a range via the old API (a vlan range maps to a tunnel range). Signed-off-by:
-
Nikolay Aleksandrov authored
The vlan tunnel code changes vlan options, it shouldn't touch port or bridge options so we can constify the port argument. This would later help us to re-use these functions from the vlan options code. Signed-off-by:
-
Nikolay Aleksandrov authored
It is more appropriate name as it shows the intent of why we need to check the options' state. It also allows us to give meaning to the two arguments of the function: the first is the current vlan (v_curr) being checked if it could enter the range ending in the second one (range_end). Signed-off-by:
-
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: 100GB Enterprise MAC support Adds the support for Enterprise MAC IP version which allows operating speeds up to 100GB. Patch 1/4, adds the support in XPCS for XLGMII interface that is used in this kind of Enterprise MAC IPs. Patch 2/4, adds the XLGMII interface support in stmmac. Patch 3/4, adds the HW specific support for Enterprise MAC. We end in patch 4/4, by updating stmmac documentation to mention the support for this new IP version. ==================== Signed-off-by: -
Jose Abreu authored
Add the Enterprise MAC support to the list of supported IP versions and the newly added XLGMII interface support. Signed-off-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
-
Jose Abreu authored
Adds the support for Enterprise MAC IP version which is very similar to XGMAC. It's so similar that we just need to check the device id and add new speeds definitions and some minor callbacks. Signed-off-by:
-
Jose Abreu authored
Add XLGMII support for stmmac including the list of speeds and defines for them. Signed-off-by:
-
Jose Abreu authored
Add XLGMII support for XPCS. This does not include Autoneg feature. Signed-off-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic bits and bytes These are a few little updates to the ionic driver while we are in between other feature work. While these are mostly Fixes, they are almost all low priority and needn't be promoted to net. The one higher need is patch 1, but it is fixing something that hasn't made it out of net-next yet. v3: allow decode of unknown transciever and use type codes from sfp.h v2: add Fixes tags to patches 1-4, and a little description for patch 5 ==================== Signed-off-by: -
Shannon Nelson authored
Add decoding for a new firmware error code. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
If we don't recognize the transceiver type, set the xcvr type and data length such that ethtool can at least print the first 256 bytes and the reader can figure out why the transceiver is not recognized. While we're here, we can update the phy_id type values to use the enum values in sfp.h. Fixes: 4d03e00a ("ionic: Add initial ethtool support") Signed-off-by:
-
Shannon Nelson authored
Remove the adminq's napi struct when tearing down the adminq. Fixes: 1d062b7b ("ionic: Add basic adminq support") Signed-off-by:
-
Shannon Nelson authored
Don't bother de-initing RSS if it wasn't selected. Fixes: aa319881 ("ionic: Add RSS support") Signed-off-by:
-
Shannon Nelson authored
If we don't set a port type, the devlink code will eventually print a WARN in the kernel log. Because the mgmt device is not really a useful port, don't register it as a devlink port. Fixes: b3f064e9 ("ionic: add support for device id 0x1004") Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== net_sched: allow use of hrtimer slack Packet schedulers have used hrtimers with exact expiry times. Some of them can afford having a slack, in order to reduce the number of timer interrupts and feed bigger batches to increase efficiency. FQ for example does not care if throttled packets are sent with an additional (small) delay. Original observation of having maybe too many interrupts was made by Willem de Bruijn. v2: added strict netlink checking (Jakub Kicinski) ==================== Signed-off-by: -
Eric Dumazet authored
Add a new attribute to control the fq qdisc hrtimer slack. Default is set to 10 usec. When/if packets are throttled, fq set up an hrtimer that can lead to one interrupt per packet in the throttled queue. By using a timer slack, we allow better use of timer interrupts, by giving them a chance to call multiple timer callbacks at each hardware interrupt. Also, giving a slack allows FQ to dequeue batches of packets instead of a single one, thus increasing xmit_more efficiency. This has no negative effect on the rate a TCP flow can sustain, since each TCP flow maintains its own precise vtime (tp->tcp_wstamp_ns) v2: added strict netlink checking (as feedback from Jakub Kicinski) Tested: 1000 concurrent flows all using paced packets. 1,000,000 packets sent per second. Before the patch : $ vmstat 2 10 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 60726784 23628 3485992 0 0 138 1 977 535 0 12 87 0 0 0 0 0 60714700 23628 3485628 0 0 0 0 1568827 26462 0 22 78 0 0 1 0 0 60716012 23628 3485656 0 0 0 0 1570034 26216 0 22 78 0 0 0 0 0 60722420 23628 3485492 0 0 0 0 1567230 26424 0 22 78 0 0 0 0 0 60727484 23628 3485556 0 0 0 0 1568220 26200 0 22 78 0 0 2 0 0 60718900 23628 3485380 0 0 0 40 1564721 26630 0 22 78 0 0 2 0 0 60718096 23628 3485332 0 0 0 0 1562593 26432 0 22 78 0 0 0 0 0 60719608 23628 3485064 0 0 0 0 1563806 26238 0 22 78 0 0 1 0 0 60722876 23628 3485236 0 0 0 130 1565874 26566 0 22 78 0 0 1 0 0 60722752 23628 3484908 0 0 0 0 1567646 26247 0 22 78 0 0 After the patch, slack of 10 usec, we can see a reduction of interrupts per second, and a small decrease of reported cpu usage. $ vmstat 2 10 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 60722564 23628 3484728 0 0 133 1 696 545 0 13 87 0 0 1 0 0 60722568 23628 3484824 0 0 0 0 977278 25469 0 20 80 0 0 0 0 0 60716396 23628 3484764 0 0 0 0 979997 25326 0 20 80 0 0 0 0 0 60713844 23628 3484960 0 0 0 0 981394 25249 0 20 80 0 0 2 0 0 60720468 23628 3484916 0 0 0 0 982860 25062 0 20 80 0 0 1 0 0 60721236 23628 3484856 0 0 0 0 982867 25100 0 20 80 0 0 1 0 0 60722400 23628 3484456 0 0 0 8 982698 25303 0 20 80 0 0 0 0 0 60715396 23628 3484428 0 0 0 0 981777 25176 0 20 80 0 0 0 0 0 60716520 23628 3486544 0 0 0 36 978965 27857 0 21 79 0 0 0 0 0 60719592 23628 3486516 0 0 0 22 977318 25106 0 20 80 0 0 Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
qdisc_watchdog_schedule_range_ns() can use the newly added slack and avoid rearming the hrtimer a bit earlier than the current value. This patch has no effect if delta_ns parameter is zero. Note that this means the max slack is potentially doubled. Signed-off-by:
-
Eric Dumazet authored
Some packet schedulers might want to add a slack when programming hrtimers. This can reduce number of interrupts and increase batch sizes and thus give good xmit_more savings. This commit adds qdisc_watchdog_schedule_range_ns() helper, with an extra delta_ns parameter. Legacy qdisc_watchdog_schedule_n() becomes an inline passing a zero slack. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== net: rename flow_action stats and set NFP type Jiri, I hope this is okay with you, I just dropped the "type" from the helper and value names, and now things should be able to fit on a line, within 80 characters. Second patch makes the NFP able to offload DELAYED stats, which is the type it supports. ==================== Signed-off-by: -
Jakub Kicinski authored
NFP flower offload uses delayed stats. Kernel recently gained the ability to specify stats types. Make nfp accept DELAYED stats, not just the catch all "any". Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
flow_action_hw_stats_types_check() helper takes one of the FLOW_ACTION_HW_STATS_*_BIT values as input. If we align the arguments to the opening bracket of the helper there is no way to call this helper and stay under 80 characters. Remove the "types" part from the new flow_action helpers and enum values. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: improve phy_driver callback handle_interrupt did_interrupt() clears the interrupt, therefore handle_interrupt() can not check which event triggered the interrupt. To overcome this constraint and allow more flexibility for customer interrupt handlers, let's decouple handle_interrupt() from parts of the phylib interrupt handling. Custom interrupt handlers now have to implement the did_interrupt() functionality in handle_interrupt() if needed. Fortunately we have just one custom interrupt handler so far (in the mscc PHY driver), convert it to the changed API and make use of the benefits. ==================== Signed-off-by: -
Heiner Kallweit authored
Trigger the respective interrupt handler functionality only if the related interrupt source bit is set. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
did_interrupt() clears the interrupt, therefore handle_interrupt() can not check which event triggered the interrupt. To overcome this constraint and allow more flexibility for customer interrupt handlers, let's decouple handle_interrupt() from parts of the phylib interrupt handling. Custom interrupt handlers now have to implement the did_interrupt() functionality in handle_interrupt() if needed. Fortunately we have just one custom interrupt handler so far (in the mscc PHY driver), convert it to the changed API. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== ethtool: consolidate irq coalescing - last part Convert remaining drivers following the groundwork laid in a recent patch set [1] and continued in [2], [3], [4], [5]. The aim of the effort is to consolidate irq coalescing parameter validation in the core. This set is the sixth and last installment. It converts the remaining 8 drivers in drivers/net/ethernet. The last patch makes declaring supported IRQ coalescing parameters a requirement. [1] https://lore.kernel.org/netdev/20200305051542.991898-1-kuba@kernel.org/ [2] https://lore.kernel.org/netdev/20200306010602.1620354-1-kuba@kernel.org/ [3] https://lore.kernel.org/netdev/20200310021512.1861626-1-kuba@kernel.org/ [4] https://lore.kernel.org/netdev/20200311223302.2171564-1-kuba@kernel.org/ [5] https://lore.kernel.org/netdev/20200313040803.2367590-1-kuba@kernel.org/ ==================== Signed-off-by:
-
Jakub Kicinski authored
Now that all in-tree drivers have been updated we can make the supported_coalesce_params mandatory. To save debugging time in case some driver was missed (or is out of tree) add a warning when netdev is registered with set_coalesce but without supported_coalesce_params. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver already correctly rejected all unsupported parameters. No functional changes. Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver already correctly rejected all unsupported parameters. No functional changes. Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver already correctly rejected all unsupported parameters. While at it remove unnecessary zeroing on get. No functional changes. Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. Signed-off-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Jakub Kicinski authored
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. The check for use_adaptive_tx_coalesce will now be done by the core. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
- 17 Mar, 2020 4 commits
-
-
David S. Miller authored
Pengcheng Yang says: ==================== tcp: fix stretch ACK bugs in congestion control modules "stretch ACKs" (caused by LRO, GRO, delayed ACKs or middleboxes) can cause serious performance shortfalls in common congestion control algorithms. Neal Cardwell submitted a series of patches starting with commit e73ebb08 ("tcp: stretch ACK fixes prep") to handle stretch ACKs and fixed stretch ACK bugs in Reno and CUBIC congestion control algorithms. This patch series continues to fix bic, scalable, veno and yeah congestion control algorithms to handle stretch ACKs. Changes in v2: - Provide [PATCH 0/N] to describe the modifications of this patch series ==================== Signed-off-by:
-
Pengcheng Yang authored
Change Yeah to properly handle stretch ACKs in additive increase mode by passing in the count of ACKed packets to tcp_cong_avoid_ai(). In addition, we re-implemented the scalable path using tcp_cong_avoid_ai() and removed the pkts_acked variable. Signed-off-by:
Pengcheng Yang <yangpc@wangsu.com> Signed-off-by:
-
Pengcheng Yang authored
Change Veno to properly handle stretch ACKs in additive increase mode by passing in the count of ACKed packets to tcp_cong_avoid_ai(). Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Pengcheng Yang authored
No code logic has been changed in this patch. Signed-off-by:
-
