* [net-next PATCH 0/6] net: frag performance tuning cachelines for NUMA/SMP systems
From: Jesper Dangaard Brouer @ 2013-01-24 14:04 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller, Florian Westphal
Cc: Jesper Dangaard Brouer, netdev, Pablo Neira Ayuso, Cong Wang,
Patrick McHardy, Herbert Xu, Daniel Borkmann
This patchset is a new partly respin of my fragmentation optimization
patches: http://thread.gmane.org/gmane.linux.network/250914
This is not the complete patchset, from previously. In this patchset,
I primarily focus on adjusting cacheline for better SMP/NUMA
performance.
Once this patchset have been agreed upon, I will continue and respin
the rest of my patches.
This time around, I have created a frag DoS generator, via the tool
trafgen (http://netsniff-ng.org/). To create a stable DoS scenario
(no longer relying on frame dropping due to disabled flow-control).
Two 10G interfaces are under-test, and uses Ethernet flow-control. A
third interface is used for generating the DoS attack (this interface
is also 10G, but it does not need to be, as 500Kpps DoS is enough).
Test types summary (netperf):
Test-20G64K == 2x10G with 65K fragments
Test-20G3F == 2x10G with 3x fragments (3*1472 bytes)
Test-20G64K+DoS == Same as 20G64K with frag DoS
Test-20G3F+DoS == Same as 20G3F with frag DoS
Patch list:
Patch-01 - net: cacheline adjust struct netns_frags for better frag performance
Patch-02 - net: cacheline adjust struct inet_frags for better frag performance
Patch-03 - net: cacheline adjust struct inet_frag_queue
Patch-04 - net: frag helper functions for mem limit tracking
Patch-05 - net: use lib/percpu_counter API for fragmentation mem accounting
Patch-06 - net: frag, move LRU list maintenance outside of rwlock
Performance table summary:
Test-type: Test-20G64K Test-20G3F 20G64K+DoS 20G3F+DoS
---------- ----------- ---------- ---------- ---------
net-next: 15114.5 Mbit/s 8954.21 2444.28 3918.01 Mbit/s
Patch-01: 16075.8 Mbit/s 8976.18 2621.49 4072.79 Mbit/s
Patch-02: 17806.9 Mbit/s 9280.32 2478.62 4274.59 Mbit/s
Patch-03: 17317.4 Mbit/s 9308.62 2546.05 4336.59 Mbit/s
Patch-04: 17635.9 Mbit/s 9256.16 2535.25 4327.63 Mbit/s
Patch-05: 18027.0 Mbit/s 9918.99 2492.62 3621.68 Mbit/s
Patch-06: 18486.7 Mbit/s 10723.20 3657.85 4560.64 Mbit/s
I cannot explain the under-DoS regression that patch-05/percpu_counter
introduces. But patch-06/LRU-lock corrects the situation again.
Below is a testlab setup description, with links to the trafgen DoS
packet config used.
---
Jesper Dangaard Brouer (6):
net: frag, move LRU list maintenance outside of rwlock
net: use lib/percpu_counter API for fragmentation mem accounting
net: frag helper functions for mem limit tracking
net: cacheline adjust struct inet_frag_queue
net: cacheline adjust struct inet_frags for better frag performance
net: cacheline adjust struct netns_frags for better frag performance
include/linux/percpu_counter.h | 2 -
include/net/inet_frag.h | 85 ++++++++++++++++++++++++++++---
include/net/ipv6.h | 2 -
net/ipv4/inet_fragment.c | 39 ++++++++------
net/ipv4/ip_fragment.c | 28 ++++------
net/ipv6/netfilter/nf_conntrack_reasm.c | 11 ++--
net/ipv6/reassembly.c | 10 +---
7 files changed, 120 insertions(+), 57 deletions(-)
Testlab
=======
Server setup
------------
The machine acting as a server:
- 2x CPU (E5-2630)
- Thus a NUMA arch/machine
- 4x 10Gbit/s ports
- NICs 2x Intel Dual port 82599 based (driver ixgbe)
Setup:
- Interfaces uses Ethernet flow control
- Flush all iptables
- Remove all iptables related module.
- Kill irqbalance
- Pin each 10G NIC port to a *single* CPU each
Pinning can easily be done by command hacks::
for x in /proc/irq/*/eth8*/../smp_affinity_list ; do echo 1 > $x; done
for x in /proc/irq/*/eth9*/../smp_affinity_list ; do echo 3 > $x; done
for x in /proc/irq/*/eth31*/../smp_affinity_list; do echo 6 > $x; done
for x in /proc/irq/*/eth32*/../smp_affinity_list; do echo 8 > $x; done
Notice NUMA setting: The CPU to NIC tying is carefully choosen
according to the NUMA node setup. Thus, NICs connected to a PCI-e
slot that is connected to a physical CPU socket are tied together.
Choosing only a single CPU per NIC (port) is just to ease provoking
and debugging this performance issue. (In real setups, you can choose
more CPU, just remember the NUMA node in the equation).
Tools
-----
Netperf is used, with option -T to ensure CPU binding.
The netserver processes, are NAPI pinned::
numactl -m0 -c0 netserver
numactl -m1 -c 1 netserver -p 1337
I now have a frag DoS generator, created via the tool:
trafgen (see: http://netsniff-ng.org/)
Trafgen packet config file:
http://people.netfilter.org/hawk/frag_work/trafgen/frag_packet03_small_frag.txf
Notice, I'm using features of trafgen, recently developed by Daniel
Borkmann, thus you need the latest git tree to use my trafgen packet
config.
git://github.com/borkmann/netsniff-ng.git
Command line:
trafgen --dev eth51 --conf frag_packet03_small_frag.txf -V -k 100 --cpus 2
Tests types
-----------
Test(20G64K) UDP-64K 2x 10Gbit/s with no DoS traffic:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
export SIZE=$((65507)); export TIME=$((20)); export LOG=/tmp/netperf.log ;\
netperf -p 1337 -H 192.168.31.2 -T7,7 -t UDP_STREAM -l $TIME -- -m $SIZE >> ${LOG}.31 &\
netperf -H 192.168.81.2 -T2,2 -t UDP_STREAM -l $TIME -- -m $SIZE >> ${LOG}.81 && \
wait $! && tail -n3 ${LOG}.* && \
tail -n3 ${LOG}.{31,81} | awk 'BEGIN{sum=0;} /212992 / {sum+=$4; print " +"$4} /==/ {print " file:"$2} END{print "sum:"sum" Mbit/s"}'
Test(20G3F) UDP-3xfrags 2x 10Gbit/s with no DoS traffic:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
export SIZE=$((3*1472)); export TIME=$((20)); export LOG=/tmp/netperf.log ;\
netperf -p 1337 -H 192.168.31.2 -T7,7 -t UDP_STREAM -l $TIME -- -m $SIZE >> ${LOG}.31 &\
netperf -H 192.168.81.2 -T2,2 -t UDP_STREAM -l $TIME -- -m $SIZE >> ${LOG}.81 && \
wait $! && tail -n3 ${LOG}.* && \
tail -n3 ${LOG}.{31,81} | awk 'BEGIN{sum=0;} /212992 / {sum+=$4; print " +"$4} /==/ {print " file:"$2} END{print "sum:"sum" Mbit/s"}'
Awk script for summming results:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tail -n3 ${LOG}.{31,81} | awk 'BEGIN{sum=0;} /212992 / {sum+=$4; print " +"$4} /==/ {print " file:"$2} END{print "sum:"sum" Mbit/s"}'
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: inaccurate packet scheduling
From: Eric Dumazet @ 2013-01-24 14:01 UTC (permalink / raw)
To: Jiri Pirko; +Cc: edumazet, netdev, kuznet, jhs
In-Reply-To: <20130124080536.GA1598@minipsycho.orion>
On Thu, 2013-01-24 at 09:05 +0100, Jiri Pirko wrote:
> Tue, Jan 08, 2013 at 02:30:38PM CET, jiri@resnulli.us wrote:
> >Wed, Jan 02, 2013 at 05:34:42PM CET, eric.dumazet@gmail.com wrote:
> >>On Wed, 2013-01-02 at 16:26 +0100, Jiri Pirko wrote:
> >>> Tue, Dec 18, 2012 at 05:51:43PM CET, erdnetdev@gmail.com wrote:
> >>> >On Tue, 2012-12-18 at 08:26 -0800, Stephen Hemminger wrote:
> >>> >
> >>> >> Check kernel log for messages about clock. It could be that on the
> >>> >> machines with issues TSC is not usable for kernel clock.
> >>> >> Also turn off TSO since it screws up any form of rate control.
> >>> >
> >>> >Yes, but we should fix it eventually. I'll take a look.
> >>>
> >>> Hi Eric, did you have a chance to look at this? Or should I give it a try?
> >>
> >>I took a look, and TBF does :
> >>
> >>if (qdisc_pkt_len(skb) > q->max_size)
> >> return qdisc_reshape_fail(skb, sch);
> >>
> >>We have several choices :
> >>
> >>1) Add a one time warning
> >>
> >>2) cap dev->gso_max_size at Qdisc setup time
> >>
> >>3) Re-segment the packet instead of dropping it (if GSO packet), and
> >>call the expensive qdisc_tree_decrease_qlen() function.
> >>
> >>4) remove max_size limitation
> >>
> >
> >To my untrained eye, 2) or 4) look like a way to go. Not sure though.
>
> What do you think would be the best way Eric? Thanks.
Capping gso_max_size is a bit difficult after commit
1def9238d4aa2146924 (net_sched: more precise pkt_len computation)
If MSS is really small, we can easily get a lot of overhead
qdisc_skb_cb(skb)->pkt_len > 2 * skb->len
It looks like we need 4), maybe using same mechanism
than the one used in commit 56b765b79e9a78d
(htb: improved accuracy at high rates)
^ permalink raw reply
* Re: [PATCH v2 1/1 net-next] net: fec: add napi support to improve proformance
From: Eric Dumazet @ 2013-01-24 13:56 UTC (permalink / raw)
To: Frank Li
Cc: lznuaa, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
s.hauer
In-Reply-To: <1359014309-8636-1-git-send-email-Frank.Li@freescale.com>
On Thu, 2013-01-24 at 15:58 +0800, Frank Li wrote:
>
> static irqreturn_t
> @@ -805,6 +823,7 @@ fec_enet_interrupt(int irq, void *dev_id)
> struct net_device *ndev = dev_id;
> struct fec_enet_private *fep = netdev_priv(ndev);
> uint int_events;
> + ulong flags;
> irqreturn_t ret = IRQ_NONE;
>
> do {
> @@ -813,7 +832,14 @@ fec_enet_interrupt(int irq, void *dev_id)
>
> if (int_events & FEC_ENET_RXF) {
> ret = IRQ_HANDLED;
> - fec_enet_rx(ndev);
> +
> + spin_lock_irqsave(&fep->hw_lock, flags);
You already are in a irq safe context, spin_lock() should be ok
> + /* Disable the RX interrupt */
> + if (napi_schedule_prep(&fep->napi)) {
> + fec_enet_rx_int_is_enabled(ndev, false);
> + __napi_schedule(&fep->napi);
> + }
> + spin_unlock_irqrestore(&fep->hw_lock, flags);
spin_unlock();
> }
>
Same remark for the spin_lock_irqsave(&fep->tmreg_lock, flags) in
fec_enet_tx()
^ permalink raw reply
* Re: [PATCH RESEND] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: Hannes Frederic Sowa @ 2013-01-24 13:55 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, davem
In-Reply-To: <5100B1A2.3000908@linux-ipv6.org>
On Thu, Jan 24, 2013 at 12:59:30PM +0900, YOSHIFUJI Hideaki wrote:
> I need to do more research. I am still not convinced
> to have such destination check here because the standard
> seems silent about it, and we have several basic checks
> in standard input path and tunnel search.
Thanks, looking forward to your conclusion.
> Anyway, try_6rd() can do check for prefix as well
> but we are doing slightly different thing.
> So I think we can introduce new __check_6rd() to
> return non-6rd/6to4 addresses.
>
> bool __check_6rd(struct ip_tunnel *tunnel,
> const struct in6_addr *v6dst,
> __be32 *v4dst);
>
> If prefix matches, fill *v4dst and return true.
> Otherwise, return false.
>
> __be32 __try_6rd()
> {
> __be32 dst = 0;
> __check_6rd(tunnel, v6dst, &dst);
> return dst;
> }
I'll update the patch and send it over for review, thanks.
^ permalink raw reply
* Re: Linux 3.6.x kernel crash in tcp_slow_start / bictcp_cong_avoid with wfica
From: Hannes Frederic Sowa @ 2013-01-24 13:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, Pasi Kärkkäinen, netdev
In-Reply-To: <1358984831.12374.1227.camel@edumazet-glaptop>
On Wed, Jan 23, 2013 at 03:47:11PM -0800, Eric Dumazet wrote:
> On Thu, 2013-01-24 at 00:41 +0100, Hannes Frederic Sowa wrote:
> > On Wed, Jan 23, 2013 at 03:26:42PM -0800, Stephen Hemminger wrote:
> > > I see no problems when using Citrix.
> > > This is a normal strace of the program wifca (in idle loop)
> >
> > Thanks, could you also have a look at setsockopts while socket creation and
> > connection establishment?
>
> As I said, tp->snd_cwnd is set to 0 by a bug in TCP stack.
I saw this, too, but hoped to see a reproduceable pattern of setsockopts
(window clamping, switching of congestion control) that could make citrix in
some way the special application which causes this.
> Probably a combination of changed sysctls, and a genuine bug.
>
> Please give us /etc/sysctl.conf content.
>
> Adding some BUG_ON(!tp->snd_cwnd) on every writes to tp->snd_cwnd should
> catch the bug.
But this is much more convenient, yes. :)
^ permalink raw reply
* Re: [RFC] net: usbnet: prevent buggy devices from killing us
From: Bjørn Mork @ 2013-01-24 13:42 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2556579.vjYlY1iKn5-7ztolUikljGernLeA6q8OA@public.gmane.org>
Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
> On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote:
>> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
>> > On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
>> >
>> >> Sorry for being daft, but how do I code the "20 among the last 30" part
>> >> there?
>> >
>> > Just by agreeing that you can live with false negatives but not false positives
>> >
>> > if (++counter > 30) {
>> > counter = bogus = 0;
>> > } else {
>> > if (is_bogus(packet)
>> > bogus++;
>> > if (bogus > counter/2)
>
> Should probably be something like bogus > counter/2 + 10
right
>> > throttle();
>> > }
>>
>> So, add two new counters to struct usbnet for this? That seems a little
>> overkill to me, but I don't see how else to implement anything like that.
>
> Memory is cheap.
OK
>> It is still not completely clear to me how the throttling/unthrottling
>> should be done. It tested with static counters (to avoid having to
>> rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
>> Still on top of my previous patch just for safety while testing, as I am
>> fed up of having to reboot all the time :-)
>>
>> Doing the flag test in rx_submit seems simpler than trying to track all
>> the places this is called. Still checking the dev->done.qlen to be able
>> to unthrottle.
>
> Ideally we would do some error handling. Does the device keep spewing
> zero packets for all eternity?
Yes. The only way to get rid of the bug once it has triggered seems to
be powering the device off/on. So unthrottling is not important for
this device. But I guess it will be for other devices with more
temporary problems.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/1 net-next] net: fec: add napi support to improve proformance
From: Florian Fainelli @ 2013-01-24 13:11 UTC (permalink / raw)
To: Frank Li
Cc: lznuaa, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
s.hauer
In-Reply-To: <1359014309-8636-1-git-send-email-Frank.Li@freescale.com>
On 01/24/2013 08:58 AM, Frank Li wrote:
65,6 +566,20 @@ fec_timeout(struct net_device *ndev)
> }
>
> static void
> +fec_enet_rx_int_is_enabled(struct net_device *ndev, bool enabled)
> +{
> + struct fec_enet_private *fep = netdev_priv(ndev);
> + uint int_events;
> +
> + int_events = readl(fep->hwp + FEC_IMASK);
> + if (enabled)
> + int_events |= FEC_ENET_RXF;
> + else
> + int_events &= ~FEC_ENET_RXF;
> + writel(int_events, fep->hwp + FEC_IMASK);
> +}
This function is badly named with respect to what it does. A better name
would be fec_enet_rx_interrupt_set() for instance.
--
Florian
^ permalink raw reply
* Re: [RFC] net: usbnet: prevent buggy devices from killing us
From: Oliver Neukum @ 2013-01-24 13:12 UTC (permalink / raw)
To: Bjørn Mork
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87y5fig32r.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote:
> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
> > On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
> >
> >> Sorry for being daft, but how do I code the "20 among the last 30" part
> >> there?
> >
> > Just by agreeing that you can live with false negatives but not false positives
> >
> > if (++counter > 30) {
> > counter = bogus = 0;
> > } else {
> > if (is_bogus(packet)
> > bogus++;
> > if (bogus > counter/2)
Should probably be something like bogus > counter/2 + 10
> > throttle();
> > }
>
> So, add two new counters to struct usbnet for this? That seems a little
> overkill to me, but I don't see how else to implement anything like that.
Memory is cheap.
> It is still not completely clear to me how the throttling/unthrottling
> should be done. It tested with static counters (to avoid having to
> rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
> Still on top of my previous patch just for safety while testing, as I am
> fed up of having to reboot all the time :-)
>
> Doing the flag test in rx_submit seems simpler than trying to track all
> the places this is called. Still checking the dev->done.qlen to be able
> to unthrottle.
Ideally we would do some error handling. Does the device keep spewing
zero packets for all eternity?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] net: usbnet: prevent buggy devices from killing us
From: Joe Perches @ 2013-01-24 13:01 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Bjørn Mork, Oliver Neukum, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <51012B76.1060600-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
On Thu, 2013-01-24 at 16:39 +0400, Sergei Shtylyov wrote:
> On 24-01-2013 14:25, Bjørn Mork wrote:
> > A device sending 0 length frames as fast as it can has been
> > observed killing the host system due to the resulting memory
> > pressure.
[]
> > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
[]
> > + /* Do not let a device flood us to death! */
> > + if (dev->done.qlen > 1024) {
> > + netif_dbg(dev, rx_err, dev->net, "done queue filling up (%u) - throttling\n", dev->done.qlen);
> > + usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
> > + usb_free_urb (urb);
>
> Run your patch thru scripts/checkpatch.pl please
And maybe ratelimit the netif_dbg
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
From: Tom St Denis @ 2013-01-24 13:00 UTC (permalink / raw)
To: Steffen Klassert
Cc: Herbert Xu, netdev, linux-kernel, linux-crypto, David Miller,
Jussi Kivilinna
In-Reply-To: <20130124125234.GL9147@secunet.com>
----- Original Message -----
> From: "Steffen Klassert" <steffen.klassert@secunet.com>
> To: "Tom St Denis" <tstdenis@elliptictech.com>
> Cc: "Herbert Xu" <herbert@gondor.apana.org.au>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-crypto@vger.kernel.org, "David Miller" <davem@davemloft.net>, "Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>
> Sent: Thursday, 24 January, 2013 7:52:34 AM
> Subject: Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
>
> On Thu, Jan 24, 2013 at 07:37:50AM -0500, Tom St Denis wrote:
> >
> > Also a question for the netdev folk, in order to be timely would it
> > be acceptable to patch ah4 and then ah6 with the AEAD changes? Or
> > would the team require both to be patched simultaneously?
> >
>
> We would need patches for both, but the changes to ah4/ah6 should
> e very similar.
I suspect, I just don't know how my time table will look like so I was trying to not block the submission of one by the other. Fortunately, I don't need hardware to test these changes so I can probably skunkwork them from home.
Tom
^ permalink raw reply
* Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
From: Steffen Klassert @ 2013-01-24 12:52 UTC (permalink / raw)
To: Tom St Denis
Cc: Herbert Xu, netdev, linux-kernel, linux-crypto, David Miller,
Jussi Kivilinna
In-Reply-To: <909599053.113808.1359031070783.JavaMail.root@elliptictech.com>
On Thu, Jan 24, 2013 at 07:37:50AM -0500, Tom St Denis wrote:
>
> Also a question for the netdev folk, in order to be timely would it be acceptable to patch ah4 and then ah6 with the AEAD changes? Or would the team require both to be patched simultaneously?
>
We would need patches for both, but the changes to ah4/ah6 should
e very similar.
^ permalink raw reply
* Re: [RFC] net: usbnet: prevent buggy devices from killing us
From: Bjørn Mork @ 2013-01-24 12:47 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb, netdev
In-Reply-To: <1809412.hrq33TVdWp@linux-5eaq.site>
Oliver Neukum <oneukum@suse.de> writes:
> On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
>
>> Sorry for being daft, but how do I code the "20 among the last 30" part
>> there?
>
> Just by agreeing that you can live with false negatives but not false positives
>
> if (++counter > 30) {
> counter = bogus = 0;
> } else {
> if (is_bogus(packet)
> bogus++;
> if (bogus > counter/2)
> throttle();
> }
So, add two new counters to struct usbnet for this? That seems a little
overkill to me, but I don't see how else to implement anything like that.
It is still not completely clear to me how the throttling/unthrottling
should be done. It tested with static counters (to avoid having to
rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
Still on top of my previous patch just for safety while testing, as I am
fed up of having to reboot all the time :-)
Doing the flag test in rx_submit seems simpler than trying to track all
the places this is called. Still checking the dev->done.qlen to be able
to unthrottle.
Was this along the lines you thought?
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 85c7ffd..e3a1d63 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -380,6 +382,13 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
unsigned long lockflags;
size_t size = dev->rx_urb_size;
+
+ if (test_bit(EVENT_RX_THROTTLE, &dev->flags) && dev->done.qlen > 0) {
+ netif_dbg(dev, rx_err, dev->net, "%s: EVENT_RX_THROTTLE: (done.qlen=%u)\n", __func__, dev->done.qlen);
+ usb_free_urb(urb);
+ return -ENOLINK;
+ }
+
/* Do not let a device flood us to death! */
if (dev->done.qlen > 1024) {
netif_dbg(dev, rx_err, dev->net, "done queue filling up (%u) - throttling\n", dev->done.qlen);
@@ -482,6 +491,7 @@ static void rx_complete (struct urb *urb)
struct usbnet *dev = entry->dev;
int urb_status = urb->status;
enum skb_state state;
+ static int counter, bogus;
skb_put (skb, urb->actual_length);
state = rx_done;
@@ -547,6 +557,17 @@ block:
break;
}
+ /* keep track of bogus packet ratio */
+ if (++counter > 30) {
+ counter = bogus = 0;
+ clear_bit(EVENT_RX_THROTTLE, &dev->flags);
+ } else {
+ if (state == rx_cleanup)
+ bogus++;
+ if (bogus > counter/2)
+ set_bit(EVENT_RX_THROTTLE, &dev->flags);
+ }
+
state = defer_bh(dev, skb, &dev->rxq, state);
if (urb) {
^ permalink raw reply related
* Re: [PATCH v2] sctp: set association state to established in dupcook_a handler
From: Neil Horman @ 2013-01-24 12:39 UTC (permalink / raw)
To: xufengzhang.main; +Cc: vyasevich, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <1358995474-28369-1-git-send-email-xufengzhang.main@gmail.com>
On Thu, Jan 24, 2013 at 10:44:34AM +0800, xufengzhang.main@gmail.com wrote:
> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>
> While sctp handling a duplicate COOKIE-ECHO and the action is
> 'Association restart', sctp_sf_do_dupcook_a() will processing
> the unexpected COOKIE-ECHO for peer restart, but it does not set
> the association state to SCTP_STATE_ESTABLISHED, so the association
> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
> This violates the sctp specification:
> RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
> Action
> A) In this case, the peer may have restarted. .....
> After this, the endpoint shall enter the ESTABLISHED state.
>
> To resolve this problem, adding a SCTP_CMD_NEW_STATE cmd to the
> command list before SCTP_CMD_REPLY cmd, this will set the restart
> association to SCTP_STATE_ESTABLISHED state properly and also avoid
> I-bit being set in the DATA chunk header when COOKIE_ACK is bundled
> with DATA chunks.
>
> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
> ---
> v2:
> - Put the SCTP_CMD_NEW_STATE command before SCTP_CMD_REPLY and after SCTP_CMD_EVENT_ULP
> suggested by Vlad and Neil
> - Improve the last paragraph of the commit header
>
> net/sctp/sm_statefuns.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 618ec7e..5131fcf 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -1779,8 +1779,10 @@ static sctp_disposition_t sctp_sf_do_dupcook_a(struct net *net,
>
> /* Update the content of current association. */
> sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
> - sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
> + sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
> + SCTP_STATE(SCTP_STATE_ESTABLISHED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
> return SCTP_DISPOSITION_CONSUME;
>
> nomem_ev:
> --
> 1.7.0.2
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [RFC] net: usbnet: prevent buggy devices from killing us
From: Sergei Shtylyov @ 2013-01-24 12:39 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Oliver Neukum, linux-usb, netdev
In-Reply-To: <1359023152-32576-1-git-send-email-bjorn@mork.no>
Hello.
On 24-01-2013 14:25, Bjørn Mork wrote:
> A device sending 0 length frames as fast as it can has been
> observed killing the host system due to the resulting memory
> pressure. We handle the done queue as fast as we can, so
> if this queue is filling up then that is an indication that we
> are under too heavy pressure. Refusing further allocations
> until the done queue is handled prevents the buggy device
> from taking the system down.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
[...]
> drivers/net/usb/usbnet.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index f34b2eb..85c7ffd 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -380,6 +380,14 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
> unsigned long lockflags;
> size_t size = dev->rx_urb_size;
>
> + /* Do not let a device flood us to death! */
> + if (dev->done.qlen > 1024) {
> + netif_dbg(dev, rx_err, dev->net, "done queue filling up (%u) - throttling\n", dev->done.qlen);
> + usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
> + usb_free_urb (urb);
Run your patch thru scripts/checkpatch.pl please -- spaces before parens
are not allowed.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
From: Tom St Denis @ 2013-01-24 12:37 UTC (permalink / raw)
To: Steffen Klassert
Cc: Herbert Xu, netdev, linux-kernel, linux-crypto, David Miller,
Jussi Kivilinna
In-Reply-To: <20130124123210.GK9147@secunet.com>
----- Original Message -----
> From: "Steffen Klassert" <steffen.klassert@secunet.com>
> To: "Jussi Kivilinna" <jussi.kivilinna@mbnet.fi>
> Cc: "Herbert Xu" <herbert@gondor.apana.org.au>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-crypto@vger.kernel.org, "Tom St Denis" <tstdenis@elliptictech.com>, "David Miller" <davem@davemloft.net>
> Sent: Thursday, 24 January, 2013 7:32:10 AM
> Subject: Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
>
> On Thu, Jan 24, 2013 at 01:25:46PM +0200, Jussi Kivilinna wrote:
> >
> > Maybe it would be cleaner to not mess with pfkeyv2.h at all, but
> > instead mark algorithms that do not support pfkey with flag. See
> > patch below.
> >
>
> Yes, would be an option too. I would be fine with that,
> but let's here if someone else has an opinion on this.
> Anyway, we need a solution to integrate Tom's patch soon.
Has anyone addressed the testmgr issues too? I wasn't able to run the self-tests so I don't even know if the vectors were copied correctly.
Also a question for the netdev folk, in order to be timely would it be acceptable to patch ah4 and then ah6 with the AEAD changes? Or would the team require both to be patched simultaneously?
Tom
^ permalink raw reply
* Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
From: Steffen Klassert @ 2013-01-24 12:32 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Herbert Xu, netdev, linux-kernel, linux-crypto, Tom St Denis,
David Miller
In-Reply-To: <20130124112410.8535.75598.stgit@localhost6.localdomain6>
On Thu, Jan 24, 2013 at 01:25:46PM +0200, Jussi Kivilinna wrote:
>
> Maybe it would be cleaner to not mess with pfkeyv2.h at all, but instead mark algorithms that do not support pfkey with flag. See patch below.
>
Yes, would be an option too. I would be fine with that,
but let's here if someone else has an opinion on this.
Anyway, we need a solution to integrate Tom's patch soon.
> Then I started looking up if sadb_alg_id is being used somewhere outside pfkey. Seems that its value is just being copied around.. but at "http://lxr.linux.no/linux+v3.7/net/xfrm/xfrm_policy.c#L1991" it's used as bit-index. So do larger values than 31 break some stuff? Can multiple algorithms have same sadb_alg_id value? Also in af_key.c, sadb_alg_id being used as bit-index.
>
Herbert tried to address this already in git commit c5d18e984
([IPSEC]: Fix catch-22 with algorithm IDs above 31) some years
ago.
But this looks still messy. If the aalgos, ealgos and calgos mask is ~0,
we allow all algorithms. If this is not the case, xfrm and pfkey check
the aalgos mask against the algorithm ID, only pfkey checks the ealgo
mask and noone checks the calgos mask.
^ permalink raw reply
* Re: Doubts about listen backlog and tcp_max_syn_backlog
From: Leandro Lucarella @ 2013-01-24 12:22 UTC (permalink / raw)
To: Rick Jones; +Cc: Eric Dumazet, netdev, linux-kernel
In-Reply-To: <510039C8.7040401@hp.com>
On Wed, Jan 23, 2013 at 11:28:08AM -0800, Rick Jones wrote:
> >Then if syncookies are enabled, the time spent in connect() shouldn't be
> >bigger than 3 seconds even if SYNs are being "dropped" by listen, right?
>
> Do you mean if "ESTABLISHED" connections are dropped because the
> listen queue is full? I don't think I would put that as "SYNs being
> dropped by listen" - too easy to confuse that with an actual
> dropping of a SYN segment.
I was just kind of quoting the name given by netstat: "SYNs to LISTEN
sockets dropped" (for kernel 3.0, I noticed newer kernels don't have
this stat anymore, or the name was changed). I still don't know if we
are talking about the same thing.
> But yes, I would not expect a connect() call to remain incomplete
> for any longer than it took to receive an SYN|ACK from the other
> end.
So the only reason to experience these high times spent in connect()
should be because a SYN or SYN|ACK was actually loss in a lower layer,
like an error in the network device or a transmission error?
> That would be 3 (,9, 21, etc...) seconds on a kernel with 3
> seconds as the initial retransmission timeout.
Which can't be changed without recompiling, right?
Thanks!
--
Leandro Lucarella
sociomantic labs GmbH
http://www.sociomantic.com
^ permalink raw reply
* Re: [B.A.T.M.A.N.] batman-adv: Unable to add interface in LXC
From: Antonio Quartulli @ 2013-01-24 12:17 UTC (permalink / raw)
To: Pau Koning; +Cc: Marek Lindner, b.a.t.m.a.n, netdev
In-Reply-To: <CANiGF99LSHAOsKiW=mwR9v3pvEXAV8_8BcBJYzxddZ2rzCQW5A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
Hello Pau,
On Mon, Jan 21, 2013 at 10:11:15AM +0100, Pau Koning wrote:
> > Did you check your kernel log messages ? I'd expect batman-adv to print
> > something there in case of an error.
>
> No output at all
Sorry for the long delay. However batman-adv does not support lxc at the moment.
Therefore the error you are getting is likely to be related to this.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net-next V2 6/6] net/mlx4_en: Initialize RFS filters lock and list in init_netdev
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
filters_lock might have been used while it was re-initialized.
Moved filters_lock and filters_list initialization to init_netdev instead of
alloc_resources which is called every time the device is configured.
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 805e242..9c42812 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1454,9 +1454,6 @@ int mlx4_en_alloc_resources(struct mlx4_en_priv *priv)
priv->dev->rx_cpu_rmap = alloc_irq_cpu_rmap(priv->rx_ring_num);
if (!priv->dev->rx_cpu_rmap)
goto err;
-
- INIT_LIST_HEAD(&priv->filters);
- spin_lock_init(&priv->filters_lock);
#endif
return 0;
@@ -1651,6 +1648,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
if (err)
goto out;
+#ifdef CONFIG_RFS_ACCEL
+ INIT_LIST_HEAD(&priv->filters);
+ spin_lock_init(&priv->filters_lock);
+#endif
+
/* Allocate page for receive rings */
err = mlx4_alloc_hwq_res(mdev->dev, &priv->res,
MLX4_EN_PAGE_SIZE, MLX4_EN_PAGE_SIZE);
--
1.7.8.2
^ permalink raw reply related
* [PATCH net-next V2 4/6] net/mlx4_core: Return proper error code when __mlx4_add_one fails
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Jack Morgenstein,
Eugenia Emantayev
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
Returning 0 (success) when in fact we are aborting the load, leads to kernel
panic when unloading the module. Fix that by returning the actual error code.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index e1bafff..983fd3d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2169,7 +2169,8 @@ slave_start:
dev->num_slaves = MLX4_MAX_NUM_SLAVES;
else {
dev->num_slaves = 0;
- if (mlx4_multi_func_init(dev)) {
+ err = mlx4_multi_func_init(dev);
+ if (err) {
mlx4_err(dev, "Failed to init slave mfunc"
" interface, aborting.\n");
goto err_cmd;
@@ -2193,7 +2194,8 @@ slave_start:
/* In master functions, the communication channel must be initialized
* after obtaining its address from fw */
if (mlx4_is_master(dev)) {
- if (mlx4_multi_func_init(dev)) {
+ err = mlx4_multi_func_init(dev);
+ if (err) {
mlx4_err(dev, "Failed to init master mfunc"
"interface, aborting.\n");
goto err_close;
@@ -2210,6 +2212,7 @@ slave_start:
mlx4_enable_msi_x(dev);
if ((mlx4_is_mfunc(dev)) &&
!(dev->flags & MLX4_FLAG_MSI_X)) {
+ err = -ENOSYS;
mlx4_err(dev, "INTx is not supported in multi-function mode."
" aborting.\n");
goto err_free_eq;
--
1.7.8.2
^ permalink raw reply related
* [PATCH net-next V2 5/6] net/mlx4_en: Fix a race when closing TX queue
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Eric Dumazet, Yevgeny Petrilin,
Eugenia Emantayev
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
There is a possible race where the TX completion handler can clean the
entire TX queue between the decision that the queue is full and actually
closing it. To avoid this situation, check again if the queue is really
full, if not, reopen the transmit and continue with sending the packet.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.com>
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 16af338..1e793e3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -588,7 +588,21 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
netif_tx_stop_queue(ring->tx_queue);
priv->port_stats.queue_stopped++;
- return NETDEV_TX_BUSY;
+ /* If queue was emptied after the if, and before the
+ * stop_queue - need to wake the queue, or else it will remain
+ * stopped forever.
+ * Need a memory barrier to make sure ring->cons was not
+ * updated before queue was stopped.
+ */
+ wmb();
+
+ if (unlikely(((int)(ring->prod - ring->cons)) <=
+ ring->size - HEADROOM - MAX_DESC_TXBBS)) {
+ netif_tx_wake_queue(ring->tx_queue);
+ priv->port_stats.wake_queue++;
+ } else {
+ return NETDEV_TX_BUSY;
+ }
}
/* Track current inflight packets for performance analysis */
--
1.7.8.2
^ permalink raw reply related
* [PATCH net-next V2 3/6] net/mlx4_en: Use the correct netif lock on ndo_set_rx_mode
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai, Eugenia Emantayev
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
From: Eugenia Emantayev <eugenia@mellanox.com>
The device multicast list is protected by netif_addr_lock_bh in the networking core, we should
use this locking practice in mlx4_en too.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Reviewed-by: Yevgeny Petrilin <yevgenyp@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index bab8cec..805e242 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -767,9 +767,9 @@ static void mlx4_en_do_set_multicast(struct work_struct *work)
/* Update multicast list - we cache all addresses so they won't
* change while HW is updated holding the command semaphor */
- netif_tx_lock_bh(dev);
+ netif_addr_lock_bh(dev);
mlx4_en_cache_mclist(dev);
- netif_tx_unlock_bh(dev);
+ netif_addr_unlock_bh(dev);
list_for_each_entry(mclist, &priv->mc_list, list) {
mcast_addr = mlx4_en_mac_to_u64(mclist->addr);
mlx4_SET_MCAST_FLTR(mdev->dev, priv->port,
--
1.7.8.2
^ permalink raw reply related
* [PATCH net-next V2 2/6] net/mlx4_en: Fix traffic loss under promiscuous mode
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Amir Vadai, Aviad Yehezkel, Eugenia Emantayev,
Hadar Hen Zion
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
From: Aviad Yehezkel <aviadye@mellanox.com>
When port is stopped and flow steering mode is not device managed: promisc QP
rule wasn't removed from MCG table.
Added code to remove it in all flow steering modes.
In addition, promsic rule removal should be in stop port and not in start
port - moved it accordingly.
Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com>
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 35 +++++++++++++++++------
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index b6c645f..bab8cec 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1167,15 +1167,6 @@ int mlx4_en_start_port(struct net_device *dev)
/* Must redo promiscuous mode setup. */
priv->flags &= ~(MLX4_EN_FLAG_PROMISC | MLX4_EN_FLAG_MC_PROMISC);
- if (mdev->dev->caps.steering_mode ==
- MLX4_STEERING_MODE_DEVICE_MANAGED) {
- mlx4_flow_steer_promisc_remove(mdev->dev,
- priv->port,
- MLX4_FS_PROMISC_UPLINK);
- mlx4_flow_steer_promisc_remove(mdev->dev,
- priv->port,
- MLX4_FS_PROMISC_ALL_MULTI);
- }
/* Schedule multicast task to populate multicast list */
queue_work(mdev->workqueue, &priv->mcast_task);
@@ -1227,6 +1218,32 @@ void mlx4_en_stop_port(struct net_device *dev)
/* Set port as not active */
priv->port_up = false;
+ /* Promsicuous mode */
+ if (mdev->dev->caps.steering_mode ==
+ MLX4_STEERING_MODE_DEVICE_MANAGED) {
+ priv->flags &= ~(MLX4_EN_FLAG_PROMISC |
+ MLX4_EN_FLAG_MC_PROMISC);
+ mlx4_flow_steer_promisc_remove(mdev->dev,
+ priv->port,
+ MLX4_FS_PROMISC_UPLINK);
+ mlx4_flow_steer_promisc_remove(mdev->dev,
+ priv->port,
+ MLX4_FS_PROMISC_ALL_MULTI);
+ } else if (priv->flags & MLX4_EN_FLAG_PROMISC) {
+ priv->flags &= ~MLX4_EN_FLAG_PROMISC;
+
+ /* Disable promiscouos mode */
+ mlx4_unicast_promisc_remove(mdev->dev, priv->base_qpn,
+ priv->port);
+
+ /* Disable Multicast promisc */
+ if (priv->flags & MLX4_EN_FLAG_MC_PROMISC) {
+ mlx4_multicast_promisc_remove(mdev->dev, priv->base_qpn,
+ priv->port);
+ priv->flags &= ~MLX4_EN_FLAG_MC_PROMISC;
+ }
+ }
+
/* Detach All multicasts */
memset(&mc_list[10], 0xff, ETH_ALEN);
mc_list[5] = priv->port; /* needed for B0 steering support */
--
1.7.8.2
^ permalink raw reply related
* [PATCH net-next V2 0/6] Mellanox Ethernet driver updates 2013-01-16
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai
Hi Dave,
These are all small bug fixes to the Mellanox mlx4 driver, patches done against
net-next commit d59577b "sk-filter: Add ability to lock a socket filter program"
Changes from V1:
- added memory barrier to "Fix a race when closing TX queue"
- Fixed indentation
Changes from V0:
- Removed patch "Set carrier to off when a port is stopped"
Need some time to make sure using netif_device_detach instead of
netif_carrier_off, as suggested by Ben, won't break anything.
Thanks,
Amir
Amir Vadai (2):
net/mlx4_en: Fix a race when closing TX queue
net/mlx4_en: Initialize RFS filters lock and list in init_netdev
Aviad Yehezkel (1):
net/mlx4_en: Fix traffic loss under promiscuous mode
Eugenia Emantayev (2):
net/mlx4_en: Issue the dump eth statistics command under lock
net/mlx4_en: Use the correct netif lock on ndo_set_rx_mode
Jack Morgenstein (1):
net/mlx4_core: Return proper error code when __mlx4_add_one fails
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 55 ++++++++++++++++--------
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 16 ++++++-
drivers/net/ethernet/mellanox/mlx4/main.c | 7 ++-
3 files changed, 57 insertions(+), 21 deletions(-)
--
1.7.8.2
^ permalink raw reply
* [PATCH net-next V2 1/6] net/mlx4_en: Issue the dump eth statistics command under lock
From: Amir Vadai @ 2013-01-24 11:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Amir Vadai, Eugenia Emantayev
In-Reply-To: <1359028459-30961-1-git-send-email-amirv@mellanox.com>
From: Eugenia Emantayev <eugenia@mellanox.com>
Performing the DUMP_ETH_STATS firmware command outside the lock leads to kernel
panic when data structures such as RX/TX rings are freed in parallel, e.g when
one changes the mtu or ring sizes.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index b467513..b6c645f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -977,12 +977,12 @@ static void mlx4_en_do_get_stats(struct work_struct *work)
struct mlx4_en_dev *mdev = priv->mdev;
int err;
- err = mlx4_en_DUMP_ETH_STATS(mdev, priv->port, 0);
- if (err)
- en_dbg(HW, priv, "Could not update stats\n");
-
mutex_lock(&mdev->state_lock);
if (mdev->device_up) {
+ err = mlx4_en_DUMP_ETH_STATS(mdev, priv->port, 0);
+ if (err)
+ en_dbg(HW, priv, "Could not update stats\n");
+
if (priv->port_up)
mlx4_en_auto_moderation(priv);
--
1.7.8.2
^ permalink raw reply related
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