* [PATCH 3.16 304/366] netlink: Do not subscribe to non-existent groups
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, Herbert Xu, Dmitry Safonov, David S. Miller, netdev,
Steffen Klassert
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
commit 7acf9d4237c46894e0fa0492dd96314a41742e84 upstream.
Make ABI more strict about subscribing to group > ngroups.
Code doesn't check for that and it looks bogus.
(one can subscribe to non-existing group)
Still, it's possible to bind() to all possible groups with (-1)
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -927,6 +927,7 @@ static int netlink_bind(struct socket *s
if (err)
return err;
}
+ groups &= (1UL << nlk->ngroups) - 1;
if (nlk->portid)
if (nladdr->nl_pid != nlk->portid)
^ permalink raw reply
* [PATCH 3.16 345/366] p54: memset(0) whole array
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, linux-wireless, netdev, Jiri Slaby, Kalle Valo,
Christian Lamparter
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.
gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
Fix that by passing the correct size to memset.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/p54/fwio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -486,7 +486,7 @@ int p54_scan(struct p54_common *priv, u1
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
- memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+ memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
sizeof(struct p54_pa_curve_data_sample) *
min((u8)8, curve_data->points_per_channel));
^ permalink raw reply
* [PATCH 3.16 310/366] netlink: Don't shift on 64 for ngroups
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, Herbert Xu, Dmitry Safonov, netdev, David S. Miller,
Steffen Klassert
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058 upstream.
It's legal to have 64 groups for netlink_sock.
As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.
The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.
Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/netlink/af_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -930,8 +930,8 @@ static int netlink_bind(struct socket *s
if (nlk->ngroups == 0)
groups = 0;
- else
- groups &= (1ULL << nlk->ngroups) - 1;
+ else if (nlk->ngroups < 8*sizeof(groups))
+ groups &= (1UL << nlk->ngroups) - 1;
if (nlk->portid)
if (nladdr->nl_pid != nlk->portid)
^ permalink raw reply
* Re: [PATCH net-next 1/2] PCI: add USR vendor id
From: kbuild test robot @ 2018-11-11 10:08 UTC (permalink / raw)
To: Heiner Kallweit
Cc: kbuild-all, Bjorn Helgaas, David Miller, netdev@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <71caf048-3f24-6241-b39c-ad1f5bd086c9@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
Hi Heiner,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Heiner-Kallweit/r8169-add-USR-PCI-vendor-id/20181111-155553
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64
All errors (new ones prefixed by >>):
>> drivers/isdn//hardware/mISDN/w6692.c:1404:23: error: 'PCI_DEVICE_ID_USR_6692' undeclared here (not in a function); did you mean 'PCI_DEVICE_ID_SI_6202'?
PCI_VENDOR_ID_USR, PCI_DEVICE_ID_USR_6692, 0, 0,
^~~~~~~~~~~~~~~~~~~~~~
PCI_DEVICE_ID_SI_6202
vim +1404 drivers/isdn//hardware/mISDN/w6692.c
707b2ce6 Karsten Keil 2009-07-22 1399
e8336ed0 Arvind Yadav 2017-07-15 1400 static const struct pci_device_id w6692_ids[] = {
707b2ce6 Karsten Keil 2009-07-22 1401 { PCI_VENDOR_ID_DYNALINK, PCI_DEVICE_ID_DYNALINK_IS64PH,
707b2ce6 Karsten Keil 2009-07-22 1402 PCI_ANY_ID, PCI_ANY_ID, 0, 0, (ulong)&w6692_map[0]},
707b2ce6 Karsten Keil 2009-07-22 1403 { PCI_VENDOR_ID_WINBOND2, PCI_DEVICE_ID_WINBOND2_6692,
707b2ce6 Karsten Keil 2009-07-22 @1404 PCI_VENDOR_ID_USR, PCI_DEVICE_ID_USR_6692, 0, 0,
707b2ce6 Karsten Keil 2009-07-22 1405 (ulong)&w6692_map[2]},
707b2ce6 Karsten Keil 2009-07-22 1406 { PCI_VENDOR_ID_WINBOND2, PCI_DEVICE_ID_WINBOND2_6692,
707b2ce6 Karsten Keil 2009-07-22 1407 PCI_ANY_ID, PCI_ANY_ID, 0, 0, (ulong)&w6692_map[1]},
707b2ce6 Karsten Keil 2009-07-22 1408 { }
707b2ce6 Karsten Keil 2009-07-22 1409 };
707b2ce6 Karsten Keil 2009-07-22 1410 MODULE_DEVICE_TABLE(pci, w6692_ids);
707b2ce6 Karsten Keil 2009-07-22 1411
:::::: The code at line 1404 was first introduced by commit
:::::: 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240 mISDN: Add driver for Winbond cards
:::::: TO: Karsten Keil <keil@b1-systems.de>
:::::: CC: Karsten Keil <keil@b1-systems.de>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 52329 bytes --]
^ permalink raw reply
* RE,
From: Miss Juliet Muhammad @ 2018-11-11 10:10 UTC (permalink / raw)
To: Recipients
Hello,
My Name is Juliet Muhammad from Turkey, I very happy to contact you because i want to be your friend and business partner hope you don't mind writing me back I came across your e-mail contact prior a private search while in need of your assistance.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-11 10:26 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20181111090350.5d0c230f@redhat.com>
W dniu 11.11.2018 o 09:03, Jesper Dangaard Brouer pisze:
> On Sat, 10 Nov 2018 23:19:50 +0100
> Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>> W dniu 10.11.2018 o 23:06, Jesper Dangaard Brouer pisze:
>>> On Sat, 10 Nov 2018 20:56:02 +0100
>>> Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>>
>>>> W dniu 10.11.2018 o 20:49, Paweł Staszewski pisze:
>>>>> W dniu 10.11.2018 o 20:34, Jesper Dangaard Brouer pisze:
>>>>>> On Fri, 9 Nov 2018 23:20:38 +0100 Paweł Staszewski
>>>>>> <pstaszewski@itcare.pl> wrote:
>>>>>>
>>>>>>> W dniu 08.11.2018 o 20:12, Paweł Staszewski pisze:
> [...]
>>> Do notice, the per CPU squeeze is not too large.
>> Yes - but im searching invisible thing now :) something invisible is
>> slowing down packet processing :)
>> So trying to find any counter that have something to do with packet
>> processing.
> NOTICE, I have given you the counters you need (below)
Yes noticed this :)
>>> [...]
>>>>>>> Remember those tests are now on two separate connectx5 connected to
>>>>>>> two separate pcie x16 gen 3.0
>>>>>> That is strange... I still suspect some HW NIC issue, can you provide
>>>>>> ethtool stats info via tool:
>>>>>>
>>>>>> https://github.com/netoptimizer/network-testing/blob/master/bin/ethtool_stats.pl
>>>>>>
>>>>>> $ ethtool_stats.pl --dev enp175s0 --dev enp216s0
>>>>>>
>>>>>> The tool remove zero-stats counters and report per sec stats. It makes
>>>>>> it easier to spot that is relevant for the given workload.
>>>>> yes mlnx have just too many counters that are always 0 for my case :)
>>>>> Will try this also
>>>>>
>>>> But still alot of non 0 counters
>>>> Show adapter(s) (enp175s0 enp216s0) statistics (ONLY that changed!)
>>>> Ethtool(enp175s0) stat: 8891 ( 8,891) <= ch0_arm /sec
>>> [...]
>>>
>>> I have copied the stats over in another document so I can better looks
>>> at it... and I've found some interesting stats.
>>>
>>> E.g. we can see that the NIC hardware is dropping packets.
>>>
>>> RX-drops on enp175s0:
>>>
>>> (enp175s0) stat: 4850734036 ( 4,850,734,036) <= rx_bytes /sec
>>> (enp175s0) stat: 5069043007 ( 5,069,043,007) <= rx_bytes_phy /sec
>>> -218308971 ( -218,308,971) Dropped bytes /sec
>>>
>>> (enp175s0) stat: 139602 ( 139,602) <= rx_discards_phy /sec
>>>
>>> (enp175s0) stat: 3717148 ( 3,717,148) <= rx_packets /sec
>>> (enp175s0) stat: 3862420 ( 3,862,420) <= rx_packets_phy /sec
>>> -145272 ( -145,272) Dropped packets /sec
>>>
>>>
>>> RX-drops on enp216s0 is less:
>>>
>>> (enp216s0) stat: 2592286809 ( 2,592,286,809) <= rx_bytes /sec
>>> (enp216s0) stat: 2633575771 ( 2,633,575,771) <= rx_bytes_phy /sec
>>> -41288962 ( -41,288,962) Dropped bytes /sec
>>>
>>> (enp216s0) stat: 464 (464) <= rx_discards_phy /sec
>>>
>>> (enp216s0) stat: 4971677 ( 4,971,677) <= rx_packets /sec
>>> (enp216s0) stat: 4975563 ( 4,975,563) <= rx_packets_phy /sec
>>> -3886 ( -3,886) Dropped packets /sec
>>>
>
> I would recommend, that you use ethtool stats and monitor rx_discards_phy.
> The PHY are the counters from the hardware, and it shows that packets
> are getting dropped at HW level. This can be because software is not
> fast enough to empty RX-queue, but in this case where CPUs are mostly
> idle I don't think that is the case.
>
That is why i was searching some counter for software - where is
something wrong.
Cause in earlier reports from ethtool there was also phy drops reported
- just when cpu's was saturated that was normal for me that phy can drop
packets if no more cpu cycles available to pickup them from hw
But in case where i have 50% idle cpu's - there should be no problem -
that is why i start to modify ethtool params for tx/rx ring and coalescence
Currently waiting for more traffic with new ethtool settings:
ethtool -g enp175s0
Ring parameters for enp175s0:
Pre-set maximums:
RX: 8192
RX Mini: 0
RX Jumbo: 0
TX: 8192
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 128
ethtool -c enp175s0
Coalesce parameters for enp175s0:
Adaptive RX: off TX: on
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
dmac: 32517
rx-usecs: 64
rx-frames: 128
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 8
tx-frames: 128
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
Both ports same settings.
Current traffic:
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
| iface Rx Tx Total
==============================================================================
enp175s0: 37.85 Gb/s 7.77 Gb/s
45.62 Gb/s
enp216s0: 7.80 Gb/s 37.90 Gb/s
45.70 Gb/s
------------------------------------------------------------------------------
total: 45.61 Gb/s 45.63 Gb/s
91.24 Gb/s
and mpstat for cpu's
Average: CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %gnice %idle
Average: all 0.33 0.00 1.48 0.01 0.00 12.11 0.00
0.00 0.00 86.06
Average: 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 1 0.00 0.00 0.90 0.00 0.00 0.00 0.00
0.00 0.00 99.10
Average: 2 0.10 0.00 0.20 0.80 0.00 0.00 0.00
0.00 0.00 98.90
Average: 3 0.10 0.00 0.30 0.00 0.00 0.00 0.00
0.00 0.00 99.60
Average: 4 14.10 0.00 1.00 0.00 0.00 0.00 0.00
0.00 0.00 84.90
Average: 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 6 0.00 0.00 1.50 0.00 0.00 0.00 0.00
0.00 0.00 98.50
Average: 7 0.20 0.00 2.00 0.00 0.00 0.00 0.00
0.00 0.00 97.80
Average: 8 0.10 0.00 0.40 0.00 0.00 0.00 0.00
0.00 0.00 99.50
Average: 9 0.00 0.00 0.60 0.00 0.00 0.00 0.00
0.00 0.00 99.40
Average: 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 11 0.00 0.00 5.60 0.00 0.00 0.00 0.00
0.00 0.00 94.40
Average: 12 0.00 0.00 4.10 0.00 0.00 0.00 0.00
0.00 0.00 95.90
Average: 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 14 0.00 0.00 1.90 0.00 0.00 27.30 0.00
0.00 0.00 70.80
Average: 15 0.00 0.00 2.10 0.00 0.00 26.00 0.00
0.00 0.00 71.90
Average: 16 0.00 0.00 2.10 0.00 0.00 25.40 0.00
0.00 0.00 72.50
Average: 17 0.20 0.00 1.80 0.00 0.00 23.10 0.00
0.00 0.00 74.90
Average: 18 0.00 0.00 2.00 0.00 0.00 25.50 0.00
0.00 0.00 72.50
Average: 19 0.00 0.00 1.90 0.00 0.00 20.20 0.00
0.00 0.00 77.90
Average: 20 0.10 0.00 1.00 0.00 0.00 26.90 0.00
0.00 0.00 72.00
Average: 21 0.10 0.00 2.80 0.00 0.00 24.70 0.00
0.00 0.00 72.40
Average: 22 0.80 0.00 3.30 0.00 0.00 24.30 0.00
0.00 0.00 71.60
Average: 23 0.10 0.00 1.80 0.00 0.00 26.60 0.00
0.00 0.00 71.50
Average: 24 0.10 0.00 1.20 0.00 0.00 23.60 0.00
0.00 0.00 75.10
Average: 25 0.00 0.00 1.80 0.00 0.00 26.60 0.00
0.00 0.00 71.60
Average: 26 0.00 0.00 1.50 0.00 0.00 26.70 0.00
0.00 0.00 71.80
Average: 27 0.10 0.00 0.70 0.00 0.00 26.70 0.00
0.00 0.00 72.50
Average: 28 0.70 0.00 0.30 0.00 0.00 0.00 0.00
0.00 0.00 99.00
Average: 29 0.20 0.00 1.50 0.00 0.00 0.00 0.00
0.00 0.00 98.30
Average: 30 0.10 0.00 0.60 0.00 0.00 0.00 0.00
0.00 0.00 99.30
Average: 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 32 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 33 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 34 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 35 0.10 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 99.90
Average: 36 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 37 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 38 0.00 0.00 2.80 0.00 0.00 0.00 0.00
0.00 0.00 97.20
Average: 39 0.00 0.00 7.40 0.00 0.00 0.00 0.00
0.00 0.00 92.60
Average: 40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 41 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 42 0.00 0.00 2.10 0.00 0.00 28.40 0.00
0.00 0.00 69.50
Average: 43 0.00 0.00 1.60 0.00 0.00 25.00 0.00
0.00 0.00 73.40
Average: 44 0.10 0.00 1.60 0.00 0.00 23.90 0.00
0.00 0.00 74.40
Average: 45 0.00 0.00 1.60 0.00 0.00 21.00 0.00
0.00 0.00 77.40
Average: 46 0.00 0.00 2.20 0.00 0.00 28.00 0.00
0.00 0.00 69.80
Average: 47 0.00 0.00 2.80 0.00 0.00 20.30 0.00
0.00 0.00 76.90
Average: 48 0.00 0.00 2.50 0.00 0.00 21.60 0.00
0.00 0.00 75.90
Average: 49 0.00 0.00 0.80 0.00 0.00 22.50 0.00
0.00 0.00 76.70
Average: 50 0.40 0.00 3.00 0.00 0.00 23.50 0.00
0.00 0.00 73.10
Average: 51 0.60 0.00 2.50 0.00 0.00 25.00 0.00
0.00 0.00 71.90
Average: 52 0.10 0.00 1.30 0.00 0.00 20.70 0.00
0.00 0.00 77.90
Average: 53 0.00 0.00 2.20 0.00 0.00 22.80 0.00
0.00 0.00 75.00
Average: 54 0.00 0.00 1.40 0.00 0.00 20.80 0.00
0.00 0.00 77.80
Average: 55 0.00 0.00 2.10 0.00 0.00 21.30 0.00
0.00 0.00 76.60
^ permalink raw reply
* [PATCH net-next v2] PCI: add USR vendor id and use it in r8169 and w6692 driver
From: Heiner Kallweit @ 2018-11-11 10:50 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Karsten Keil
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <9af6abf5-ba01-155f-17d1-ca4b71b74fa6@gmail.com>
The PCI vendor id of U.S. Robotics isn't defined in pci_ids.h so far,
only ISDN driver w6692 has a private definition. Move the definition
to pci_ids.h and use it also in the r8169 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- The original patch caused a build failure in w6692 driver because
it broke the private PCI device id definition.
I hope it's ok to submit this through the netdev tree.
---
drivers/isdn/hardware/mISDN/w6692.c | 5 -----
drivers/net/ethernet/realtek/r8169.c | 2 +-
include/linux/pci_ids.h | 4 ++++
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/w6692.c b/drivers/isdn/hardware/mISDN/w6692.c
index 5acf6ab67..f6b4f4f11 100644
--- a/drivers/isdn/hardware/mISDN/w6692.c
+++ b/drivers/isdn/hardware/mISDN/w6692.c
@@ -52,11 +52,6 @@ static const struct w6692map w6692_map[] =
{W6692_USR, "USR W6692"}
};
-#ifndef PCI_VENDOR_ID_USR
-#define PCI_VENDOR_ID_USR 0x16ec
-#define PCI_DEVICE_ID_USR_6692 0x3409
-#endif
-
struct w6692_ch {
struct bchannel bch;
u32 addr;
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1fd01688d..366a690eb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -224,7 +224,7 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_USR, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
{ 0x0001, 0x8168,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 69f0abe1b..1fac231fe 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2359,6 +2359,10 @@
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_VENDOR_ID_USR 0x16ec
+#define PCI_DEVICE_ID_USR_997902 0x0116
+#define PCI_DEVICE_ID_USR_6692 0x3409
+
#define PCI_VENDOR_ID_VITESSE 0x1725
#define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174
--
2.19.1
^ permalink raw reply related
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Stefano Brivio @ 2018-11-11 11:50 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181110214844.GL6440@orbyte.nwl.cc>
Hi Phil,
On Sat, 10 Nov 2018 22:48:44 +0100
Phil Sutter <phil@nwl.cc> wrote:
> On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
>
> > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > ts_log "[Testing ssfilter]"
> >
> > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
>
> How about using a regular expression ('test_on' calls grep with '-E')?
> E.g. this instead of the above:
>
> | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
I also thought about something similar (perhaps uglier: piping the
output through tr -s ' ' in ts_ss()).
But then I thought we might like to use this test to also check that we
don't accidentally modify spacing, so I'd rather leave it as it is,
with this patch on top.
--
Stefano
^ permalink raw reply
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Phil Sutter @ 2018-11-11 12:12 UTC (permalink / raw)
To: Stefano Brivio; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181111125039.639dd608@redhat.com>
Hi Stefano,
On Sun, Nov 11, 2018 at 12:50:39PM +0100, Stefano Brivio wrote:
> On Sat, 10 Nov 2018 22:48:44 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
> >
> > > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > > ts_log "[Testing ssfilter]"
> > >
> > > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> >
> > How about using a regular expression ('test_on' calls grep with '-E')?
> > E.g. this instead of the above:
> >
> > | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
>
> I also thought about something similar (perhaps uglier: piping the
> output through tr -s ' ' in ts_ss()).
>
> But then I thought we might like to use this test to also check that we
> don't accidentally modify spacing, so I'd rather leave it as it is,
> with this patch on top.
Fair enough, no objections from my side.
Thanks, Phil
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-11-11 22:26 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
One last pull request before heading to Vancouver for LPC, here we have:
1) Don't forget to free VSI contexts during ice driver unload, from
Victor Raj.
2) Don't forget napi delete calls during device remove in ice driver,
from Dave Ertman.
3) Don't request VLAN tag insertion of ibmvnic device when SKB doesn't
have VLAN tags at all.
4) IPV4 frag handling code has to accomodate the situation where two
threads try to insert the same fragment into the hash table at the
same time. From Eric Dumazet.
5) Relatedly, don't flow separate on protocol ports for fragmented
frames, also from Eric Dumazet.
6) Memory leaks in qed driver, from Denis Bolotin.
7) Correct valid MTU range in smsc95xx driver, from Stefan Wahren.
8) Validate cls_flower nested policies properly, from Jakub Kicinski.
9) Clearing of stats counters in mc88e6xxx driver doesn't retain
important bits in the G1_STATS_OP register causing the chip to
hang. Fix from Andrew Lunn.
Please pull, thanks a lot!
The following changes since commit 8053e5b93eca9b011f7b79bb019bf1eeaaf96c4b:
Merge tag 'trace-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2018-11-06 08:12:10 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 7236ead1b14923f3ba35cd29cce13246be83f451:
act_mirred: clear skb->tstamp on redirect (2018-11-11 10:21:31 -0800)
----------------------------------------------------------------
Akeem G Abodunrin (1):
ice: Fix dead device link issue with flow control
Alexandre Belloni (1):
net: mvneta: correct typo
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix clearing of stats counters
Anirudh Venkataramanan (4):
ice: Set carrier state and start/stop queues in rebuild
ice: Check for reset in progress during remove
ice: Remove duplicate addition of VLANs in replay path
ice: Fix typo in error message
Brett Creeley (2):
ice: Fix tx_timeout in PF driver
ice: Fix the bytecount sent to netdev_tx_sent_queue
Chinh T Cao (1):
ice: Change req_speeds to be u16
Dave Ertman (1):
ice: Fix napi delete calls for remove
David S. Miller (4):
Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge branch 'FDDI-defza-Fix-a-bunch-of-small-issues'
Merge branch 'qed-Slowpath-Queue-bug-fixes'
Merge branch 'aquantia-fixes'
Denis Bolotin (3):
qed: Fix memory/entry leak in qed_init_sp_request()
qed: Fix blocking/unlimited SPQ entries leak
qed: Fix SPQ entries not returned to pool in error flows
Dmitry Bogdanov (3):
net: aquantia: fix potential IOMMU fault after driver unbind
net: aquantia: invalid checksumm offload implementation
net: aquantia: allow rx checksum offload configuration
Eric Dumazet (2):
inet: frags: better deal with smp races
act_mirred: clear skb->tstamp on redirect
Huazhong Tan (1):
net: hns3: bugfix for not checking return value
Igor Russkikh (2):
net: aquantia: synchronized flow control between mac/phy
net: aquantia: fixed enable unicast on 32 macvlan
Jacob Keller (2):
i40e: restore NETIF_F_GSO_IPXIP[46] to netdev features
i40e: enable NETIF_F_NTUPLE and NETIF_F_HW_TC at driver load
Jakub Kicinski (1):
net: sched: cls_flower: validate nested enc_opts_policy to avoid warning
Jon Maloy (1):
tipc: fix link re-establish failure
Maciej W. Rozycki (4):
FDDI: defza: Fix SPDX annotation
FDDI: defza: Add missing comment closing
FDDI: defza: Move SMT Tx data buffer declaration next to its skb
FDDI: defza: Make the driver version string constant
Md Fahad Iqbal Polash (1):
ice: Fix flags for port VLAN
Michał Mirosław (2):
ibmvnic: fix accelerated VLAN handling
qlcnic: remove assumption that vlan_tci != 0
Miroslav Lichvar (1):
igb: shorten maximum PHC timecounter update interval
Sagiv Ozeri (1):
qed: Fix potential memory corruption
Stefan Wahren (1):
net: smsc95xx: Fix MTU range
Subash Abhinov Kasiviswanathan (1):
net: qualcomm: rmnet: Fix incorrect assignment of real_dev
Tao Ren (1):
net: phy: Allow BCM54616S PHY to setup internal TX/RX clock delay
Thor Thayer (1):
net: stmmac: Fix RX packet size > 8191
Victor Raj (1):
ice: Free VSI contexts during for unload
배석진 (1):
flow_dissector: do not dissect l4 ports for fragments
drivers/net/dsa/mv88e6xxx/global1.c | 2 ++
drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 8 ++++----
drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 6 ++++++
drivers/net/ethernet/aquantia/atlantic/aq_main.c | 10 ++++++++--
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 18 +++++++++++++++---
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 2 +-
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 35 +++++++++++++++++++++++------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 61 ++++++++++++++++++++++++++++++++++++++-----------------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c | 8 ++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h | 3 +++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h | 18 ++++++++++++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 21 +++++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++---
drivers/net/ethernet/intel/ice/ice.h | 4 +++-
drivers/net/ethernet/intel/ice/ice_common.c | 3 +++
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 ++++++-
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 2 ++
drivers/net/ethernet/intel/ice/ice_lib.c | 3 ++-
drivers/net/ethernet/intel/ice/ice_main.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------
drivers/net/ethernet/intel/ice/ice_switch.c | 12 ++++++++++++
drivers/net/ethernet/intel/ice/ice_switch.h | 2 ++
drivers/net/ethernet/intel/ice/ice_txrx.c | 11 ++++++-----
drivers/net/ethernet/intel/ice/ice_txrx.h | 17 +++++++++++++++--
drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 4 +---
drivers/net/ethernet/intel/igb/igb_ptp.c | 12 +++++++-----
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 11 ++++++++---
drivers/net/ethernet/qlogic/qed/qed_iscsi.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++++++++----
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_roce.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_sp.h | 14 ++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 22 ++++++++++++++++++++--
drivers/net/ethernet/qlogic/qed/qed_spq.c | 69 +++++++++++++++++++++++++++++++++++----------------------------------
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 8 +++++---
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/descs_com.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
drivers/net/fddi/defza.c | 7 ++++---
drivers/net/fddi/defza.h | 3 ++-
drivers/net/phy/broadcom.c | 18 ++++++++++++++++--
drivers/net/usb/smsc95xx.c | 2 ++
net/core/flow_dissector.c | 4 ++--
net/ipv4/inet_fragment.c | 29 +++++++++++++++--------------
net/sched/act_mirred.c | 3 ++-
net/sched/cls_flower.c | 14 +++++++++++++-
net/sched/sch_netem.c | 9 ---------
net/tipc/link.c | 11 +++++++----
54 files changed, 430 insertions(+), 199 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Alexander Duyck @ 2018-11-11 23:05 UTC (permalink / raw)
To: Paweł Staszewski
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <b8b1fbb7-9139-9455-69b8-8c1bed4f7c74@itcare.pl>
On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>
>
> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
> > On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
> >> page_frag_free() calls __free_pages_ok() to free the page back to
> >> Buddy. This is OK for high order page, but for order-0 pages, it
> >> misses the optimization opportunity of using Per-Cpu-Pages and can
> >> cause zone lock contention when called frequently.
> >>
> >> Paweł Staszewski recently shared his result of 'how Linux kernel
> >> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
> >> found the lock contention comes from page allocator:
> >>
> >> mlx5e_poll_tx_cq
> >> |
> >> --16.34%--napi_consume_skb
> >> |
> >> |--12.65%--__free_pages_ok
> >> | |
> >> | --11.86%--free_one_page
> >> | |
> >> | |--10.10%--queued_spin_lock_slowpath
> >> | |
> >> | --0.65%--_raw_spin_lock
> >> |
> >> |--1.55%--page_frag_free
> >> |
> >> --1.44%--skb_release_data
> >>
> >> Jesper explained how it happened: mlx5 driver RX-page recycle
> >> mechanism is not effective in this workload and pages have to go
> >> through the page allocator. The lock contention happens during
> >> mlx5 DMA TX completion cycle. And the page allocator cannot keep
> >> up at these speeds.[2]
> >>
> >> I thought that __free_pages_ok() are mostly freeing high order
> >> pages and thought this is an lock contention for high order pages
> >> but Jesper explained in detail that __free_pages_ok() here are
> >> actually freeing order-0 pages because mlx5 is using order-0 pages
> >> to satisfy its page pool allocation request.[3]
> >>
> >> The free path as pointed out by Jesper is:
> >> skb_free_head()
> >> -> skb_free_frag()
> >> -> skb_free_frag()
> >> -> page_frag_free()
> >> And the pages being freed on this path are order-0 pages.
> >>
> >> Fix this by doing similar things as in __page_frag_cache_drain() -
> >> send the being freed page to PCP if it's an order-0 page, or
> >> directly to Buddy if it is a high order page.
> >>
> >> With this change, Paweł hasn't noticed lock contention yet in
> >> his workload and Jesper has noticed a 7% performance improvement
> >> using a micro benchmark and lock contention is gone.
> >>
> >> [1]: https://www.spinics.net/lists/netdev/msg531362.html
> >> [2]: https://www.spinics.net/lists/netdev/msg531421.html
> >> [3]: https://www.spinics.net/lists/netdev/msg531556.html
> >> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
> >> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
> >> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> >> ---
> >> mm/page_alloc.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >> index ae31839874b8..91a9a6af41a2 100644
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
> >> {
> >> struct page *page = virt_to_head_page(addr);
> >>
> >> - if (unlikely(put_page_testzero(page)))
> >> - __free_pages_ok(page, compound_order(page));
> >> + if (unlikely(put_page_testzero(page))) {
> >> + unsigned int order = compound_order(page);
> >> +
> >> + if (order == 0)
> >> + free_unref_page(page);
> >> + else
> >> + __free_pages_ok(page, order);
> >> + }
> >> }
> >> EXPORT_SYMBOL(page_frag_free);
> >>
> > One thing I would suggest for Pawel to try would be to reduce the Tx
> > qdisc size on his transmitting interfaces, Reduce the Tx ring size,
> > and possibly increase the Tx interrupt rate. Ideally we shouldn't have
> > too many packets in-flight and I suspect that is the issue that Pawel
> > is seeing that is leading to the page pool allocator freeing up the
> > memory. I know we like to try to batch things but the issue is
> > processing too many Tx buffers in one batch leads to us eating up too
> > much memory and causing evictions from the cache. Ideally the Rx and
> > Tx rings and queues should be sized as small as possible while still
> > allowing us to process up to our NAPI budget. Usually I run things
> > with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
> > don't have more buffers stored there than we can place in the Tx ring.
> > Then we can avoid the extra thrash of having to pull/push memory into
> > and out of the freelists. Essentially the issue here ends up being
> > another form of buffer bloat.
> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
> <4096 producing more interface rx drops - and no_rx_buffer on network
> controller that is receiving more packets
> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
> the TX buff on connectx4 - but that changed nothing before Aaron patch
>
> After Aaron patch - decreasing TX buffer influencing total bandwidth
> that can be handled by the router/server
> Dono why before this patch there was no difference there no matter what
> i set there there was always page_alloc/slowpath on top in perf
>
>
> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
> more bandwidth with less interrupts...
The problem is if you are going for less interrupts you are setting
yourself up for buffer bloat. Basically you are going to use much more
cache and much more memory then you actually need and if things are
properly configured NAPI should take care of the interrupts anyway
since under maximum load you shouldn't stop polling normally.
One issue I have seen is people delay interrupts for as long as
possible which isn't really a good thing since most network
controllers will use NAPI which will disable the interrupts and leave
them disabled whenever the system is under heavy stress so you should
be able to get the maximum performance by configuring an adapter with
small ring sizes and for high interrupt rates.
It is easiest to think of it this way. Your total packet rate is equal
to your interrupt rate times the number of buffers you will store in
the ring. So if you have some fixed rate "X" for packets and an
interrupt rate of "i" then your optimal ring size should be "X/i". So
if you lower the interrupt rate you end up hurting the throughput
unless you increase the buffer size. However at a certain point the
buffer size starts becoming an issue. For example with UDP flows I
often see massive packet drops if you tune the interrupt rate too low
and then put the system under heavy stress.
- Alex
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2018-11-11 23:15 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20181111.142649.1250091930241970662.davem@davemloft.net>
The pull request you sent on Sun, 11 Nov 2018 14:26:49 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7a3765ed66d187071bbf56a8212f5d2bc2d2e2cc
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH net-next 0/3] tcp: tso defer improvements
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
This series makes tcp_tso_should_defer() a bit smarter :
1) MSG_EOR gives a hint to TCP to not defer some skbs
2) Second patch takes into account that head tstamp
can be in the future.
3) Third patch uses existing high resolution state variables
to have a more precise heuristic.
Eric Dumazet (3):
tcp: do not try to defer skbs with eor mark (MSG_EOR)
tcp: refine tcp_tso_should_defer() after EDT adoption
tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
net/ipv4/tcp_output.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply
* [PATCH net-next 1/3] tcp: do not try to defer skbs with eor mark (MSG_EOR)
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
Applications using MSG_EOR are giving a strong hint to TCP stack :
Subsequent sendmsg() can not append more bytes to skbs having
the EOR mark.
Do not try to TSO defer suchs skbs, there is really no hope.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 9c34b97d365d719ff76250bc9fe7fa20495a3ed2..35feadf480300cd061411d65257f06ee658daa3c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1944,6 +1944,10 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
goto send_now;
+ /* If this packet won't get more data, do not wait. */
+ if (TCP_SKB_CB(skb)->eor)
+ goto send_now;
+
win_divisor = READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_tso_win_divisor);
if (win_divisor) {
u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 2/3] tcp: refine tcp_tso_should_defer() after EDT adoption
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() last step tries to check if the probable
next ACK packet is coming in less than half rtt.
Problem is that the head->tstamp might be in the future,
so we need to use signed arithmetics to avoid overflows.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 35feadf480300cd061411d65257f06ee658daa3c..78a56cef7e397c65ad18897d550f3800e8fe8f41 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1907,10 +1907,11 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
bool *is_cwnd_limited, u32 max_segs)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
- u32 age, send_win, cong_win, limit, in_flight;
+ u32 send_win, cong_win, limit, in_flight;
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *head;
int win_divisor;
+ s64 delta;
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto send_now;
@@ -1972,9 +1973,9 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
head = tcp_rtx_queue_head(sk);
if (!head)
goto send_now;
- age = tcp_stamp_us_delta(tp->tcp_mstamp, tcp_skb_timestamp_us(head));
+ delta = tp->tcp_clock_cache - head->tstamp;
/* If next ACK is likely to come too late (half srtt), do not defer */
- if (age < (tp->srtt_us >> 4))
+ if ((s64)(delta - (u64)NSEC_PER_USEC * (tp->srtt_us >> 4)) < 0)
goto send_now;
/* Ok, it looks like it is advisable to defer. */
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 3/3] tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() first heuristic is to not defer
if last send is "old enough".
Its current implementation uses jiffies and its low granularity.
TSO autodefer performance should not rely on kernel HZ :/
After EDT conversion, we have state variables in nanoseconds that
can allow us to properly implement the heuristic.
This patch increases TSO chunk sizes on medium rate flows,
especially when receivers do not use GRO or similar aggregation.
It also reduces bursts for HZ=100 or HZ=250 kernels, making TCP
behavior more uniform.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 78a56cef7e397c65ad18897d550f3800e8fe8f41..75dcf4daca724a6819e9ecc9d0f3e6dc6df72e9b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1920,9 +1920,12 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
goto send_now;
/* Avoid bursty behavior by allowing defer
- * only if the last write was recent.
+ * only if the last write was recent (1 ms).
+ * Note that tp->tcp_wstamp_ns can be in the future if we have
+ * packets waiting in a qdisc or device for EDT delivery.
*/
- if ((s32)(tcp_jiffies32 - tp->lsndtime) > 0)
+ delta = tp->tcp_clock_cache - tp->tcp_wstamp_ns - NSEC_PER_MSEC;
+ if (delta > 0)
goto send_now;
in_flight = tcp_packets_in_flight(tp);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH net-next v3 6/6] net/ncsi: Configure multi-package, multi-channel modes with failover
From: Samuel Mendoza-Jonas @ 2018-11-12 0:38 UTC (permalink / raw)
To: Justin.Lee1, netdev; +Cc: davem, linux-kernel, openbmc
In-Reply-To: <b2c6aea94f1648648dd349d23ce61bf6@AUSX13MPS302.AMER.DELL.COM>
On Fri, 2018-11-09 at 21:58 +0000, Justin.Lee1@Dell.com wrote:
> Hi Samuel,
>
> After running more testing, I notice that the extra patch causing failover function
> to fail. Also, occasionally, I will see two channels having TX enabled if I
> send netlink command back-to-back.
>
> cat /sys/kernel/debug/ncsi_protocol/ncsi_device_
> IFIDX IFNAME NAME PID CID RX TX MP MC WP WC PC CS PS LS RU CR NQ HA
> =====================================================================
> 2 eth2 ncsi0 000 000 1 1 1 1 1 1 1 2 1 1 1 1 0 1
> 2 eth2 ncsi1 000 001 1 1 1 1 1 1 0 2 1 1 1 1 0 1
> 2 eth2 ncsi2 001 000 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> 2 eth2 ncsi3 001 001 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> =====================================================================
> MP: Multi-mode Package WP: Whitelist Package
> MC: Multi-mode Channel WC: Whitelist Channel
> PC: Primary Channel CS: Channel State IA/A/IV 1/2/3
> PS: Poll Status LS: Link Status
> RU: Running CR: Carrier OK
> NQ: Queue Stopped HA: Hardware Arbitration
>
> Thanks,
> Justin
>
>
> > From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
> > From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> > Date: Fri, 9 Nov 2018 13:11:03 +1100
> > Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
> >
> > ---
> > net/ncsi/ncsi-aen.c | 8 +++++---
> > net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
> > 2 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
> > index 39c2e9eea2ba..034cb1dc5566 100644
> > --- a/net/ncsi/ncsi-aen.c
> > +++ b/net/ncsi/ncsi-aen.c
> > @@ -93,14 +93,16 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
> > if ((had_link == has_link) || chained)
> > return 0;
> >
> > - if (!ndp->multi_package && !nc->package->multi_channel) {
> > - if (had_link)
> > - ndp->flags |= NCSI_DEV_RESHUFFLE;
> > + if (!ndp->multi_package && !nc->package->multi_channel && had_link) {
> > + ndp->flags |= NCSI_DEV_RESHUFFLE;
> > ncsi_stop_channel_monitor(nc);
> > spin_lock_irqsave(&ndp->lock, flags);
> > list_add_tail_rcu(&nc->link, &ndp->channel_queue);
> > spin_unlock_irqrestore(&ndp->lock, flags);
> > return ncsi_process_next_channel(ndp);
> > + } else {
> > + /* Configured channel came up */
> > + return 0;
>
> It is always going to else statement if multi_package and/or mutlit_channel is enabled.
>
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - pkg 0 ch 0 state down
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - had_link 1, has_link 0, chained 0
>
> These codes have no chance to run.
> if (had_link) {
> ncm = &nc->modes[NCSI_MODE_TX_ENABLE];
> if (ncsi_channel_is_last(ndp, nc)) {
> /* No channels left, reconfigure */
> return ncsi_reset_dev(&ndp->ndev);
> } else if (ncm->enable) {
> /* Need to failover Tx channel */
> ncsi_update_tx_channel(ndp, nc->package, nc, NULL);
> }
>
> > }
> >
Oops, wrote that patch a little fast it seems. This may also affect the
double-Tx above since ncsi_update_tx_channel() won't be reached.
I've attached a fixed up version below.
For the failover issue you're seeing in your previous email the issue is
likely in the ncsi_dev_state_suspend_gls state. This should send a GLS
command to all available channels, but it only does it for the current
package. Since not all packages are necessarily enabled in single-channel
mode I'll need to have a think about the neatest way to handle that, but
it's a separate issue from this patch.
Cheers,
Sam
>From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Fri, 9 Nov 2018 13:11:03 +1100
Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
---
net/ncsi/ncsi-aen.c | 16 ++++++++++------
net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 39c2e9eea2ba..76559d0eeea8 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -94,13 +94,17 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
return 0;
if (!ndp->multi_package && !nc->package->multi_channel) {
- if (had_link)
+ if (had_link) {
ndp->flags |= NCSI_DEV_RESHUFFLE;
- ncsi_stop_channel_monitor(nc);
- spin_lock_irqsave(&ndp->lock, flags);
- list_add_tail_rcu(&nc->link, &ndp->channel_queue);
- spin_unlock_irqrestore(&ndp->lock, flags);
- return ncsi_process_next_channel(ndp);
+ ncsi_stop_channel_monitor(nc);
+ spin_lock_irqsave(&ndp->lock, flags);
+ list_add_tail_rcu(&nc->link, &ndp->channel_queue);
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return ncsi_process_next_channel(ndp);
+ } else {
+ /* Configured channel came up */
+ return 0;
+ }
}
if (had_link) {
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index fa3c2144f5ba..92e59f07f9a7 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1063,17 +1063,17 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
case ncsi_dev_state_config_done:
netdev_dbg(ndp->ndev.dev, "NCSI: channel %u config done\n",
nc->id);
+ spin_lock_irqsave(&nc->lock, flags);
+ nc->state = NCSI_CHANNEL_ACTIVE;
+
if (ndp->flags & NCSI_DEV_RESET) {
/* A reset event happened during config, start it now */
- spin_lock_irqsave(&nc->lock, flags);
nc->reconfigure_needed = false;
spin_unlock_irqrestore(&nc->lock, flags);
- nd->state = ncsi_dev_state_functional;
ncsi_reset_dev(nd);
break;
}
- spin_lock_irqsave(&nc->lock, flags);
if (nc->reconfigure_needed) {
/* This channel's configuration has been updated
* part-way during the config state - start the
@@ -1092,7 +1092,6 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
break;
}
- nc->state = NCSI_CHANNEL_ACTIVE;
if (nc->modes[NCSI_MODE_LINK].data[2] & 0x1) {
hot_nc = nc;
} else {
@@ -1803,6 +1802,18 @@ int ncsi_reset_dev(struct ncsi_dev *nd)
spin_unlock_irqrestore(&ndp->lock, flags);
return 0;
}
+ } else {
+ switch (nd->state) {
+ case ncsi_dev_state_suspend_done:
+ case ncsi_dev_state_config_done:
+ case ncsi_dev_state_functional:
+ /* Ok */
+ break;
+ default:
+ /* Current reset operation happening */
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return 0;
+ }
}
if (!list_empty(&ndp->channel_queue)) {
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Paweł Staszewski @ 2018-11-12 0:39 UTC (permalink / raw)
To: Alexander Duyck
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <CAKgT0UdhcXF-ohPHPbg8onRjFabEMnbpXGmLm-27skCNzGKOgw@mail.gmail.com>
W dniu 12.11.2018 o 00:05, Alexander Duyck pisze:
> On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>
>>
>> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
>>> On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
>>>> page_frag_free() calls __free_pages_ok() to free the page back to
>>>> Buddy. This is OK for high order page, but for order-0 pages, it
>>>> misses the optimization opportunity of using Per-Cpu-Pages and can
>>>> cause zone lock contention when called frequently.
>>>>
>>>> Paweł Staszewski recently shared his result of 'how Linux kernel
>>>> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
>>>> found the lock contention comes from page allocator:
>>>>
>>>> mlx5e_poll_tx_cq
>>>> |
>>>> --16.34%--napi_consume_skb
>>>> |
>>>> |--12.65%--__free_pages_ok
>>>> | |
>>>> | --11.86%--free_one_page
>>>> | |
>>>> | |--10.10%--queued_spin_lock_slowpath
>>>> | |
>>>> | --0.65%--_raw_spin_lock
>>>> |
>>>> |--1.55%--page_frag_free
>>>> |
>>>> --1.44%--skb_release_data
>>>>
>>>> Jesper explained how it happened: mlx5 driver RX-page recycle
>>>> mechanism is not effective in this workload and pages have to go
>>>> through the page allocator. The lock contention happens during
>>>> mlx5 DMA TX completion cycle. And the page allocator cannot keep
>>>> up at these speeds.[2]
>>>>
>>>> I thought that __free_pages_ok() are mostly freeing high order
>>>> pages and thought this is an lock contention for high order pages
>>>> but Jesper explained in detail that __free_pages_ok() here are
>>>> actually freeing order-0 pages because mlx5 is using order-0 pages
>>>> to satisfy its page pool allocation request.[3]
>>>>
>>>> The free path as pointed out by Jesper is:
>>>> skb_free_head()
>>>> -> skb_free_frag()
>>>> -> skb_free_frag()
>>>> -> page_frag_free()
>>>> And the pages being freed on this path are order-0 pages.
>>>>
>>>> Fix this by doing similar things as in __page_frag_cache_drain() -
>>>> send the being freed page to PCP if it's an order-0 page, or
>>>> directly to Buddy if it is a high order page.
>>>>
>>>> With this change, Paweł hasn't noticed lock contention yet in
>>>> his workload and Jesper has noticed a 7% performance improvement
>>>> using a micro benchmark and lock contention is gone.
>>>>
>>>> [1]: https://www.spinics.net/lists/netdev/msg531362.html
>>>> [2]: https://www.spinics.net/lists/netdev/msg531421.html
>>>> [3]: https://www.spinics.net/lists/netdev/msg531556.html
>>>> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
>>>> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>>> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
>>>> ---
>>>> mm/page_alloc.c | 10 ++++++++--
>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index ae31839874b8..91a9a6af41a2 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
>>>> {
>>>> struct page *page = virt_to_head_page(addr);
>>>>
>>>> - if (unlikely(put_page_testzero(page)))
>>>> - __free_pages_ok(page, compound_order(page));
>>>> + if (unlikely(put_page_testzero(page))) {
>>>> + unsigned int order = compound_order(page);
>>>> +
>>>> + if (order == 0)
>>>> + free_unref_page(page);
>>>> + else
>>>> + __free_pages_ok(page, order);
>>>> + }
>>>> }
>>>> EXPORT_SYMBOL(page_frag_free);
>>>>
>>> One thing I would suggest for Pawel to try would be to reduce the Tx
>>> qdisc size on his transmitting interfaces, Reduce the Tx ring size,
>>> and possibly increase the Tx interrupt rate. Ideally we shouldn't have
>>> too many packets in-flight and I suspect that is the issue that Pawel
>>> is seeing that is leading to the page pool allocator freeing up the
>>> memory. I know we like to try to batch things but the issue is
>>> processing too many Tx buffers in one batch leads to us eating up too
>>> much memory and causing evictions from the cache. Ideally the Rx and
>>> Tx rings and queues should be sized as small as possible while still
>>> allowing us to process up to our NAPI budget. Usually I run things
>>> with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
>>> don't have more buffers stored there than we can place in the Tx ring.
>>> Then we can avoid the extra thrash of having to pull/push memory into
>>> and out of the freelists. Essentially the issue here ends up being
>>> another form of buffer bloat.
>> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
>> <4096 producing more interface rx drops - and no_rx_buffer on network
>> controller that is receiving more packets
>> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
>> the TX buff on connectx4 - but that changed nothing before Aaron patch
>>
>> After Aaron patch - decreasing TX buffer influencing total bandwidth
>> that can be handled by the router/server
>> Dono why before this patch there was no difference there no matter what
>> i set there there was always page_alloc/slowpath on top in perf
>>
>>
>> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
>> more bandwidth with less interrupts...
> The problem is if you are going for less interrupts you are setting
> yourself up for buffer bloat. Basically you are going to use much more
> cache and much more memory then you actually need and if things are
> properly configured NAPI should take care of the interrupts anyway
> since under maximum load you shouldn't stop polling normally.
Im trying to balance here - there is problem cause server is forwarding
all kingd of protocols packets/different size etc
The problem is im trying to go in high interrupt rate - but
Setting coalescence to adaptative for rx killing cpu's at 22Gbit/s RX
and 22Gbit with rly high interrupt rate
So adding a little more latency i can turn off adaptative rx and setup
rx-usecs from range 16-64 - and this gives me more or less interrupts -
but the problem is - always same bandwidth as maximum
>
> One issue I have seen is people delay interrupts for as long as
> possible which isn't really a good thing since most network
> controllers will use NAPI which will disable the interrupts and leave
> them disabled whenever the system is under heavy stress so you should
> be able to get the maximum performance by configuring an adapter with
> small ring sizes and for high interrupt rates.
Sure this is bad to setup rx-usec for high values - cause at some point
this will add high latency for packet traversing both sides - and start
to hurt buffers
But my problem is a little different now i have no problems with RX side
- cause i can setup anything like:
coalescence from 16 to 64
rx ring from 3000 to max 8192
And it does not change my max bw - only produces less or more interrupts.
So I start to change params for TX side - and for now i know that the
best for me is
coalescence adaptative on
TX buffer 128
This helps with max BW that for now is close to 70Gbit/s RX and 70Gbit
TX but after this change i have increasing DROPS on TX side for vlan
interfaces.
And only 50% cpu (max was 50% for 70Gbit/s)
> It is easiest to think of it this way. Your total packet rate is equal
> to your interrupt rate times the number of buffers you will store in
> the ring. So if you have some fixed rate "X" for packets and an
> interrupt rate of "i" then your optimal ring size should be "X/i". So
> if you lower the interrupt rate you end up hurting the throughput
> unless you increase the buffer size. However at a certain point the
> buffer size starts becoming an issue. For example with UDP flows I
> often see massive packet drops if you tune the interrupt rate too low
> and then put the system under heavy stress.
Yes - in normal life traffic - most of ddos'es are like this many pps
with small frames.
> - Alex
>
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the bpf tree
From: Stephen Rothwell @ 2018-11-12 0:54 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andrey Ignatov, Nitin Hande
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/filter.c
between commit:
b13b8787c95c ("bpf: Fix IPv6 dport byte order in bpf_sk_lookup_udp")
from the bpf tree and commit:
c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP hookpoint.")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/core/filter.c
index 9a1327eb25fa,53d50fb75ea1..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -4852,19 -4867,19 +4867,18 @@@ static struct sock *sk_lookup(struct ne
} else {
struct in6_addr *src6 = (struct in6_addr *)&tuple->ipv6.saddr;
struct in6_addr *dst6 = (struct in6_addr *)&tuple->ipv6.daddr;
- int sdif = inet6_sdif(skb);
- u16 hnum = ntohs(tuple->ipv6.dport);
if (proto == IPPROTO_TCP)
- sk = __inet6_lookup(net, &tcp_hashinfo, skb, 0,
+ sk = __inet6_lookup(net, &tcp_hashinfo, NULL, 0,
src6, tuple->ipv6.sport,
- dst6, hnum,
+ dst6, ntohs(tuple->ipv6.dport),
dif, sdif, &refcounted);
else if (likely(ipv6_bpf_stub))
sk = ipv6_bpf_stub->udp6_lib_lookup(net,
src6, tuple->ipv6.sport,
- dst6, hnum,
+ dst6, tuple->ipv6.dport,
dif, sdif,
- &udp_table, skb);
+ &udp_table, NULL);
#endif
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net 0/4] qed: Miscellaneous bug fixes
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
Hi Dave,
This patch series fixes several unrelated bugs across the driver.
Please consider applying to net.
Thanks,
Denis
Denis Bolotin (3):
qed: Fix PTT leak in qed_drain()
qed: Fix overriding offload_tc by protocols without APP TLV
qed: Fix reading wrong value in loop condition
Michal Kalderon (1):
qed: Fix rdma_info structure allocation
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 14 ++++-----
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++---
drivers/net/ethernet/qlogic/qed/qed_int.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 50 +++++++++++++++++-------------
drivers/net/ethernet/qlogic/qed/qed_rdma.h | 5 +++
6 files changed, 55 insertions(+), 33 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/4] qed: Fix PTT leak in qed_drain()
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
Release PTT before entering error flow.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 35fd0db..fff7f04 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1782,9 +1782,9 @@ static int qed_drain(struct qed_dev *cdev)
return -EBUSY;
}
rc = qed_mcp_drain(hwfn, ptt);
+ qed_ptt_release(hwfn, ptt);
if (rc)
return rc;
- qed_ptt_release(hwfn, ptt);
}
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/4] qed: Fix rdma_info structure allocation
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
From: Michal Kalderon <michal.kalderon@cavium.com>
Certain flows need to access the rdma-info structure, for example dcbx
update flows. In some cases there can be a race between the allocation or
deallocation of the structure which was done in roce start / roce stop and
an asynchrounous dcbx event that tries to access the structure.
For this reason, we move the allocation of the rdma_info structure to be
similar to the iscsi/fcoe info structures which are allocated during device
setup.
We add a new field of "active" to the struct to define whether roce has
already been started or not, and this is checked instead of whether the
pointer to the info structure.
Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init")
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++---
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 50 +++++++++++++++++-------------
drivers/net/ethernet/qlogic/qed/qed_rdma.h | 5 +++
3 files changed, 45 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 7ceb2b9..cff1410 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -185,6 +185,10 @@ void qed_resc_free(struct qed_dev *cdev)
qed_iscsi_free(p_hwfn);
qed_ooo_free(p_hwfn);
}
+
+ if (QED_IS_RDMA_PERSONALITY(p_hwfn))
+ qed_rdma_info_free(p_hwfn);
+
qed_iov_free(p_hwfn);
qed_l2_free(p_hwfn);
qed_dmae_info_free(p_hwfn);
@@ -1081,6 +1085,12 @@ int qed_resc_alloc(struct qed_dev *cdev)
goto alloc_err;
}
+ if (QED_IS_RDMA_PERSONALITY(p_hwfn)) {
+ rc = qed_rdma_info_alloc(p_hwfn);
+ if (rc)
+ goto alloc_err;
+ }
+
/* DMA info initialization */
rc = qed_dmae_info_alloc(p_hwfn);
if (rc)
@@ -2102,11 +2112,8 @@ int qed_hw_start_fastpath(struct qed_hwfn *p_hwfn)
if (!p_ptt)
return -EAGAIN;
- /* If roce info is allocated it means roce is initialized and should
- * be enabled in searcher.
- */
if (p_hwfn->p_rdma_info &&
- p_hwfn->b_rdma_enabled_in_prs)
+ p_hwfn->p_rdma_info->active && p_hwfn->b_rdma_enabled_in_prs)
qed_wr(p_hwfn, p_ptt, p_hwfn->rdma_prs_search_reg, 0x1);
/* Re-open incoming traffic */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 6211343..7873d6df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -140,22 +140,34 @@ static u32 qed_rdma_get_sb_id(void *p_hwfn, u32 rel_sb_id)
return FEAT_NUM((struct qed_hwfn *)p_hwfn, QED_PF_L2_QUE) + rel_sb_id;
}
-static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_rdma_start_in_params *params)
+int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn)
{
struct qed_rdma_info *p_rdma_info;
- u32 num_cons, num_tasks;
- int rc = -ENOMEM;
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "Allocating RDMA\n");
-
- /* Allocate a struct with current pf rdma info */
p_rdma_info = kzalloc(sizeof(*p_rdma_info), GFP_KERNEL);
if (!p_rdma_info)
- return rc;
+ return -ENOMEM;
+
+ spin_lock_init(&p_rdma_info->lock);
p_hwfn->p_rdma_info = p_rdma_info;
+ return 0;
+}
+
+void qed_rdma_info_free(struct qed_hwfn *p_hwfn)
+{
+ kfree(p_hwfn->p_rdma_info);
+ p_hwfn->p_rdma_info = NULL;
+}
+
+static int qed_rdma_alloc(struct qed_hwfn *p_hwfn)
+{
+ struct qed_rdma_info *p_rdma_info = p_hwfn->p_rdma_info;
+ u32 num_cons, num_tasks;
+ int rc = -ENOMEM;
+
+ DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "Allocating RDMA\n");
+
if (QED_IS_IWARP_PERSONALITY(p_hwfn))
p_rdma_info->proto = PROTOCOLID_IWARP;
else
@@ -183,7 +195,7 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
/* Allocate a struct with device params and fill it */
p_rdma_info->dev = kzalloc(sizeof(*p_rdma_info->dev), GFP_KERNEL);
if (!p_rdma_info->dev)
- goto free_rdma_info;
+ return rc;
/* Allocate a struct with port params and fill it */
p_rdma_info->port = kzalloc(sizeof(*p_rdma_info->port), GFP_KERNEL);
@@ -298,8 +310,6 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
kfree(p_rdma_info->port);
free_rdma_dev:
kfree(p_rdma_info->dev);
-free_rdma_info:
- kfree(p_rdma_info);
return rc;
}
@@ -370,8 +380,6 @@ static void qed_rdma_resc_free(struct qed_hwfn *p_hwfn)
kfree(p_rdma_info->port);
kfree(p_rdma_info->dev);
-
- kfree(p_rdma_info);
}
static void qed_rdma_free_tid(void *rdma_cxt, u32 itid)
@@ -679,8 +687,6 @@ static int qed_rdma_setup(struct qed_hwfn *p_hwfn,
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "RDMA setup\n");
- spin_lock_init(&p_hwfn->p_rdma_info->lock);
-
qed_rdma_init_devinfo(p_hwfn, params);
qed_rdma_init_port(p_hwfn);
qed_rdma_init_events(p_hwfn, params);
@@ -727,7 +733,7 @@ static int qed_rdma_stop(void *rdma_cxt)
/* Disable RoCE search */
qed_wr(p_hwfn, p_ptt, p_hwfn->rdma_prs_search_reg, 0);
p_hwfn->b_rdma_enabled_in_prs = false;
-
+ p_hwfn->p_rdma_info->active = 0;
qed_wr(p_hwfn, p_ptt, PRS_REG_ROCE_DEST_QP_MAX_PF, 0);
ll2_ethertype_en = qed_rd(p_hwfn, p_ptt, PRS_REG_LIGHT_L2_ETHERTYPE_EN);
@@ -1236,7 +1242,8 @@ static int qed_rdma_destroy_qp(void *rdma_cxt, struct qed_rdma_qp *qp)
u8 max_stats_queues;
int rc;
- if (!rdma_cxt || !in_params || !out_params || !p_hwfn->p_rdma_info) {
+ if (!rdma_cxt || !in_params || !out_params ||
+ !p_hwfn->p_rdma_info->active) {
DP_ERR(p_hwfn->cdev,
"qed roce create qp failed due to NULL entry (rdma_cxt=%p, in=%p, out=%p, roce_info=?\n",
rdma_cxt, in_params, out_params);
@@ -1802,8 +1809,8 @@ bool qed_rdma_allocated_qps(struct qed_hwfn *p_hwfn)
{
bool result;
- /* if rdma info has not been allocated, naturally there are no qps */
- if (!p_hwfn->p_rdma_info)
+ /* if rdma wasn't activated yet, naturally there are no qps */
+ if (!p_hwfn->p_rdma_info->active)
return false;
spin_lock_bh(&p_hwfn->p_rdma_info->lock);
@@ -1849,7 +1856,7 @@ static int qed_rdma_start(void *rdma_cxt,
if (!p_ptt)
goto err;
- rc = qed_rdma_alloc(p_hwfn, p_ptt, params);
+ rc = qed_rdma_alloc(p_hwfn);
if (rc)
goto err1;
@@ -1858,6 +1865,7 @@ static int qed_rdma_start(void *rdma_cxt,
goto err2;
qed_ptt_release(p_hwfn, p_ptt);
+ p_hwfn->p_rdma_info->active = 1;
return rc;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.h b/drivers/net/ethernet/qlogic/qed/qed_rdma.h
index 6f722ee..50d609c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.h
@@ -102,6 +102,7 @@ struct qed_rdma_info {
u16 max_queue_zones;
enum protocol_type proto;
struct qed_iwarp_info iwarp;
+ u8 active:1;
};
struct qed_rdma_qp {
@@ -176,10 +177,14 @@ struct qed_rdma_qp {
#if IS_ENABLED(CONFIG_QED_RDMA)
void qed_rdma_dpm_bar(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
void qed_rdma_dpm_conf(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
+int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn);
+void qed_rdma_info_free(struct qed_hwfn *p_hwfn);
#else
static inline void qed_rdma_dpm_conf(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) {}
static inline void qed_rdma_dpm_bar(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt) {}
+static inline int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn) {return -EINVAL}
+static inline void qed_rdma_info_free(struct qed_hwfn *p_hwfn) {}
#endif
int
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/4] qed: Fix overriding offload_tc by protocols without APP TLV
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
The TC received from APP TLV is stored in offload_tc, and should not be
set by protocols which did not receive an APP TLV. Fixed the condition
when overriding the offload_tc.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 8e8fa82..69966df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -191,7 +191,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- bool enable, u8 prio, u8 tc,
+ bool app_tlv, bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type,
enum qed_pci_personality personality)
{
@@ -210,7 +210,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
p_data->arr[type].dont_add_vlan0 = true;
/* QM reconf data */
- if (p_hwfn->hw_info.personality == personality)
+ if (app_tlv && p_hwfn->hw_info.personality == personality)
qed_hw_info_set_offload_tc(&p_hwfn->hw_info, tc);
/* Configure dcbx vlan priority in doorbell block for roce EDPM */
@@ -225,7 +225,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_update_app_info(struct qed_dcbx_results *p_data,
struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- bool enable, u8 prio, u8 tc,
+ bool app_tlv, bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type)
{
enum qed_pci_personality personality;
@@ -240,7 +240,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_hwfn, p_ptt, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_ptt, app_tlv, enable,
prio, tc, type, personality);
}
}
@@ -319,8 +319,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
enable = true;
}
- qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
- priority, tc, type);
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, true,
+ enable, priority, tc, type);
}
}
@@ -341,7 +341,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
continue;
enable = (type == DCBX_PROTOCOL_ETH) ? false : !!dcbx_version;
- qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, false, enable,
priority, tc, type);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 4/4] qed: Fix reading wrong value in loop condition
From: Denis Bolotin @ 2018-11-11 15:05 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
The value of "sb_index" is written by the hardware. Reading its value and
writing it to "index" must finish before checking the loop condition.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_int.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c b/drivers/net/ethernet/qlogic/qed/qed_int.c
index 0f0aba7..aa7504a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -992,6 +992,8 @@ static int qed_int_attentions(struct qed_hwfn *p_hwfn)
*/
do {
index = p_sb_attn->sb_index;
+ /* finish reading index before the loop condition */
+ rmb();
attn_bits = le32_to_cpu(p_sb_attn->atten_bits);
attn_acks = le32_to_cpu(p_sb_attn->atten_ack);
} while (index != p_sb_attn->sb_index);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 0/9] Use __vlan_hwaccel_*() helpers
From: Tariq Toukan @ 2018-11-11 15:26 UTC (permalink / raw)
To: David Miller, mirq-linux@rere.qmqm.pl
Cc: netdev@vger.kernel.org, ajit.khaparde@broadcom.com,
kuznet@ms2.inr.ac.ru, bridge@lists.linux-foundation.org,
xiyou.wangcong@gmail.com, coreteam@netfilter.org, fw@strlen.de,
yoshfuji@linux-ipv6.org, jhs@mojatatu.com, jiri@resnulli.us,
kadlec@blackhole.kfki.hu, linux-rdma@vger.kernel.org,
mlindner@marvell.com, netfilter-devel@vger.kernel.org,
nikolay@cumulusnetworks.com
In-Reply-To: <20181108.204523.1353698272847299871.davem@davemloft.net>
On 09/11/2018 6:45 AM, David Miller wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Fri, 09 Nov 2018 00:17:58 +0100
>
>> This series removes from networking core and driver code an assumption
>> about how VLAN tag presence is stored in an skb. This will allow to free
>> up overloading of VLAN.CFI bit to incidate tag's presence.
>
> This looks good, series applied.
>
> Thanks.
>
Hi Michal,
We started seeing the compilation errors below, they look related to
this series.
Thanks,
Tariq
02:15:09 net/8021q/vlan_core.c: In function 'vlan_do_receive':
02:15:09 net/8021q/vlan_core.c:60:2: error: implicit declaration of
function '__vlan_hwaccel_clear_tag'; did you mean
'__vlan_hwaccel_get_tag'? [-Werror=implicit-function-declaration]
02:15:09 __vlan_hwaccel_clear_tag(skb);
02:15:09 ^~~~~~~~~~~~~~~~~~~~~~~~
02:15:09 __vlan_hwaccel_get_tag
02:15:09 cc1: some warnings being treated as errors
02:15:09 make[4]: *** [scripts/Makefile.build:293:
net/8021q/vlan_core.o] Error 1
02:15:09 make[4]: *** Waiting for unfinished jobs....
02:15:11 make[3]: *** [scripts/Makefile.build:518: net/8021q] Error 2
02:15:11 make[3]: *** Waiting for unfinished jobs....
02:15:14 make[2]: *** [Makefile:1060: net] Error 2
02:15:14 make[2]: *** Waiting for unfinished jobs....
02:15:36 drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function
'mlx4_en_process_rx_cq':
02:15:36 drivers/net/ethernet/mellanox/mlx4/en_rx.c:878:4: error:
implicit declaration of function '__vlan_hwaccel_clear_tag'; did you
mean '__vlan_hwaccel_get_tag'? [-Werror=implicit-function-declaration]
02:15:36 __vlan_hwaccel_clear_tag(skb);
02:15:36 ^~~~~~~~~~~~~~~~~~~~~~~~
02:15:36 __vlan_hwaccel_get_tag
02:15:36 cc1: some warnings being treated as errors
02:15:37 make[7]: *** [scripts/Makefile.build:293:
drivers/net/ethernet/mellanox/mlx4/en_rx.o] Error 1
02:15:37 make[7]: *** Waiting for unfinished jobs....
02:15:37 make[6]: *** [scripts/Makefile.build:518:
drivers/net/ethernet/mellanox/mlx4] Error 2
02:15:37 make[6]: *** Waiting for unfinished jobs....
02:15:39 drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function
'mlx5e_grp_sw_update_stats':
02:15:39 drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1:
warning: the frame size of 1200 bytes is larger than 1024 bytes
[-Wframe-larger-than=]
02:15:39 }
02:15:39 ^
02:15:49 make[5]: *** [scripts/Makefile.build:518:
drivers/net/ethernet/mellanox] Error 2
02:15:49 make[4]: *** [scripts/Makefile.build:518: drivers/net/ethernet]
Error 2
02:15:49 make[3]: *** [scripts/Makefile.build:518: drivers/net] Error 2
02:15:49 make[2]: *** [Makefile:1060: drivers] Error 2
02:15:49 make[1]: *** [scripts/package/Makefile:63: binrpm-pkg] Error 2
02:15:49 make: *** [Makefile:1399: binrpm-pkg] Error 2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox