* Re: [Patch net-next] net_sched: act: Dont increment refcnt on replace
From: David Miller @ 2014-01-06 21:47 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <52B83580.2010601@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 23 Dec 2013 08:07:12 -0500
> Ok, let me know how this one went ;->
> I think i know how to send this way if you find it fits your workflow.
Looks better, for sure. But somehow got lost on the way to patchwork.
^ permalink raw reply
* Re: [Patch net-next 3/3] net_sched: act: action flushing missaccounting
From: David Miller @ 2014-01-06 21:47 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <1387803733-19709-4-git-send-email-jhs@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 23 Dec 2013 08:02:13 -0500
> action flushing missaccounting
> Account only for deleted actions
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] Remove unnecessary checks for act->ops
From: David Miller @ 2014-01-06 21:47 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <1387803733-19709-3-git-send-email-jhs@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 23 Dec 2013 08:02:12 -0500
> Remove unnecessary checks for act->ops
> (suggested by Eric Dumazet).
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net_sched: act: Various fixes
From: David Miller @ 2014-01-06 21:46 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <52C6AC16.4000103@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Fri, 03 Jan 2014 07:24:54 -0500
> Patches 2 + 3 are missing (from both tree and patchwork).
I'll take a look.
^ permalink raw reply
* Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback
From: Cyrill Gorcunov @ 2014-01-06 21:44 UTC (permalink / raw)
To: Florian Westphal
Cc: Andrey Vagin, netfilter-devel, netfilter, coreteam, netdev,
linux-kernel, vvs, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller
In-Reply-To: <20140106212326.GB9894@breakpoint.cc>
On Mon, Jan 06, 2014 at 10:23:26PM +0100, Florian Westphal wrote:
> >
> > No? Or there something obvious I'm missing?
>
> IMHO this isn't obvious at all :-)
>
> But, in the example above, the atomic_inc_not_zero() should fail
> until after __nf_conntrack_alloc() re-inits the refcount to 1.
>
> The mb there should make sure ____nf_conntrack_find() doesn't
> find an outdated tuple before this.
Yeah, thanks!
^ permalink raw reply
* Re: [PATCH net-next] vxlan: keep original skb ownership
From: David Miller @ 2014-01-06 21:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: sathya.perla, netdev, edumazet, stephen
In-Reply-To: <1389030871.12212.203.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 06 Jan 2014 09:54:31 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Sathya Perla posted a patch trying to address following problem :
>
> <quote>
> The vxlan driver sets itself as the socket owner for all the TX flows
> it encapsulates (using vxlan_set_owner()) and assigns it's own skb
> destructor. This causes all tunneled traffic to land up on only one TXQ
> as all encapsulated skbs refer to the vxlan socket and not the original
> socket. Also, the vxlan skb destructor breaks some functionality for
> tunneled traffic like wmem accounting and as TCP small queues and
> FQ/pacing packet scheduler.
> </quote>
>
> I reworked Sathya patch and added some explanations.
>
> vxlan_xmit() can avoid one skb_clone()/dev_kfree_skb() pair
> and gain better drop monitor accuracy, by calling kfree_skb() when
> appropriate.
>
> The UDP socket used by vxlan to perform encapsulation of xmit packets
> do not need to be alive while packets leave vxlan code. Its better
> to keep original socket ownership to get proper feedback from qdisc and
> NIC layers.
>
> We use skb->sk to
>
> A) control amount of bytes/packets queued on behalf of a socket, but
> prior vxlan code did the skb->sk transfert without any limit/control
> on vxlan socket sk_sndbuf.
>
> B) security purposes (as selinux) or netfilter uses, and I do not think
> anything is prepared to handle vxlan stacked case in this area.
>
> By not changing ownership, vxlan tunnels behave like other tunnels.
> As Stephen mentioned, we might do the same change in L2TP.
>
> Reported-by: Sathya Perla <sathya.perla@emulex.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks a lot Eric.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bridge: use DEVICE_ATTR_xx macros
From: David Miller @ 2014-01-06 21:41 UTC (permalink / raw)
To: sfeldma; +Cc: stephen, netdev, roopa, bridge, curt, shm
In-Reply-To: <20140106190044.10912.47228.stgit@monster-03.cumulusnetworks.com>
From: Scott Feldman <sfeldma@cumulusnetworks.com>
Date: Mon, 06 Jan 2014 11:00:44 -0800
> Use DEVICE_ATTR_RO/RW macros to simplify bridge sysfs attribute definitions.
>
> Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] bridge: use spin_lock_bh() in br_multicast_set_hash_max
From: David Miller @ 2014-01-06 21:41 UTC (permalink / raw)
To: cwang; +Cc: shm, sfeldma, netdev, roopa, bridge, stephen
In-Reply-To: <CAHA+R7MB4Pf=eF-7=3gGH-j1mmJLtrjxFqv0bBXF1BBd1D=kuQ@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 6 Jan 2014 11:11:45 -0800
> On Mon, Jan 6, 2014 at 11:00 AM, Scott Feldman
> <sfeldma@cumulusnetworks.com> wrote:
>> From: Curt Brune <curt@cumulusnetworks.com>
>>
>> br_multicast_set_hash_max() is called from process context in
>> net/bridge/br_sysfs_br.c by the sysfs store_hash_max() function.
>>
>> br_multicast_set_hash_max() calls spin_lock(&br->multicast_lock),
>> which can deadlock the CPU if a softirq that also tries to take the
>> same lock interrupts br_multicast_set_hash_max() while the lock is
>> held . This can happen quite easily when any of the bridge multicast
>> timers expire, which try to take the same lock.
>>
>> The fix here is to use spin_lock_bh(), preventing other softirqs from
>> executing on this CPU.
>>
>> Steps to reproduce:
>>
>> 1. Create a bridge with several interfaces (I used 4).
>> 2. Set the "multicast query interval" to a low number, like 2.
>> 3. Enable the bridge as a multicast querier.
>> 4. Repeatedly set the bridge hash_max parameter via sysfs.
>>
>> # brctl addbr br0
>> # brctl addif br0 eth1 eth2 eth3 eth4
>> # brctl setmcqi br0 2
>> # brctl setmcquerier br0 1
>>
>> # while true ; do echo 4096 > /sys/class/net/br0/bridge/hash_max; done
>>
>
>
> I think this should probably go to net instead of net-next,
> and -stable too.
Agreed, applied to 'net' and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net-gre-gro: Add GRE support to the GRO stack
From: Eric Dumazet @ 2014-01-06 21:40 UTC (permalink / raw)
To: David Miller; +Cc: hkchu, edumazet, herbert, ogerlitz, netdev
In-Reply-To: <20140106.161846.332183513263839789.davem@davemloft.net>
On Mon, 2014-01-06 at 16:18 -0500, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 06 Jan 2014 15:43:30 -0500 (EST)
>
> > That the gre offload bits won't be registered unless GRE is enabled and
> > initialized/loaded, right?
>
> In fact, it's utterly and completely bogus to make only this change.
> It breaks the build, I'm reverting:
>
> ERROR: "gre_offload_exit" [net/ipv4/gre.ko] undefined!
> ERROR: "gre_offload_init" [net/ipv4/gre.ko] undefined!
> --
Jerry, I'll send the patch to do this preparatory work in a small
and tested unit in the following hour.
Thanks.
^ permalink raw reply
* Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic
From: Or Gerlitz @ 2014-01-06 21:39 UTC (permalink / raw)
To: Tom Herbert
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CA+mtBx-aiCMyJocmDw8MfoGxWns2yppjFr8-hn6mH7yrFbMrGA@mail.gmail.com>
On Mon, Jan 6, 2014 at 8:46 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Jan 6, 2014 at 10:13 AM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>> On Mon, Jan 6, 2014 at 6:50 PM, Tom Herbert <therbert@google.com> wrote:
>>> I think this would be a good start. We can further optimize the encap
>>> path later on.
>>
>> good, did you had the chance to look on the 2nd problem I was facing,
>> e.g how to prevent gro-ing encapsulated VM (this issue will not happen
>> for non-virtualization schemes, I think) udp packets which happen to
>> carry a destination port which belongs to an encapsulation protocol?
>> as I wrote earlier here, I was thinking to add some field to struct
>> napi_gro_cb which will be zeroed when the gro stacks starts to work on
>> the skb and set once we pass udp_gro_receive, such that if we arrive
>> again to udp_gro_recieve and this field is set, which means the
>> encapsulated
>> packet is udp one, we flush.
>
> I don't see what the problem is, GRO should not be recursively applied
> to an inner UDP header for encapsulation. The guest may try to do it's
> own version of GRO on an inner UDP packet, but interpreting the
> destination port correctly is its responsibility then.
I wasn't sure what do you mean by "GRO should not be recursively applied
to an inner UDP header for encapsulation", consider these three packets p1/p2/p3
who are vxlan encapsulated with the UDP port used by vxlan being X and are
structured as follows (the arrows depict the gro travels)
p1: ip --> udp dport X --> vxlan --> ip --> tcp dportZ
p2: ip --> udp dport X --> vxlan --> ip --> udp dportY
p2: ip --> udp dport X --> vxlan --> ip --> udp dportX --> vxlan xxit!
p1 will safely land in the tcp gro code and be handled there
p2 will travel twice to the udp gro code and be flushed on the 2nd
time there since
there is no gro protocol handler for udp port Y
p3 will travel twice to the udp gro code but will not be flushed on
the 2nd time
since it has dport which is registered to have gro handler, as such
the 1st eight bytes
of its payload will be considered vxlan header and from there we will
not be going anywhere good.
My current solution is to mark packets while they manage to cross the
udp gro recv handler
and disallow crossing there twice.
^ permalink raw reply
* Re: [PATCH] hso: fix handling of modem port SERIAL_STATE notifications
From: Dan Williams @ 2014-01-06 21:39 UTC (permalink / raw)
To: David Miller
Cc: hns, j.dumon, linux-usb, netdev, linux-kernel, marek.belisko,
e.verdonck
In-Reply-To: <20140106.163036.1031013112322786.davem@davemloft.net>
On Mon, 2014-01-06 at 16:30 -0500, David Miller wrote:
> From: Dan Williams <dcbw@redhat.com>
> Date: Mon, 06 Jan 2014 10:07:29 -0600
>
> > The existing serial state notification handling expected older Option
> > devices, having a hardcoded assumption that the Modem port was always
> > USB interface #2. That isn't true for devices from the past few years.
> >
> > hso_serial_state_notification is a local cache of a USB Communications
> > Interface Class SERIAL_STATE notification from the device, and the
> > USB CDC specification (section 6.3, table 67 "Class-Specific Notifications")
> > defines wIndex as the USB interface the event applies to. For hso
> > devices this will always be the Modem port, as the Modem port is the
> > only port which is set up to receive them by the driver.
> >
> > So instead of always expecting USB interface #2, instead validate the
> > notification with the actual USB interface number of the Modem port.
> >
> > Signed-off-by: Dan Williams <dcbw@redhat.com>
> > Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
>
> Applied, although that BUG_ON() is a bit harsh. It might have been
> cleaner to just dev_warn() ratelimited or similar and return.
If the driver ever gets to that callback for any !Modem port, something
is horribly wrong, which the BUG_ON() was attempting to make explicit.
The driver only enables that callback for the Modem port, so yeah, it's
somewhat defensive. I'm happy to send a fixup if you like?
Dan
^ permalink raw reply
* Re: [PATCH] hso: fix handling of modem port SERIAL_STATE notifications
From: David Miller @ 2014-01-06 21:39 UTC (permalink / raw)
To: dcbw
Cc: hns, j.dumon, linux-usb, netdev, linux-kernel, marek.belisko,
e.verdonck
In-Reply-To: <1389044380.15419.4.camel@dcbw.local>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 06 Jan 2014 15:39:40 -0600
> If the driver ever gets to that callback for any !Modem port, something
> is horribly wrong, which the BUG_ON() was attempting to make explicit.
> The driver only enables that callback for the Modem port, so yeah, it's
> somewhat defensive. I'm happy to send a fixup if you like?
You don't have to if you think the BUG_ON() is warranted.
^ permalink raw reply
* Re: [PATCH net-next] tcp: out_of_order_queue do not use its lock
From: David Miller @ 2014-01-06 21:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1389029772.12212.190.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 06 Jan 2014 09:36:12 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> TCP out_of_order_queue lock is not used, as queue manipulation
> happens with socket lock held and we therefore use the lockless
> skb queue routines (as __skb_queue_head())
>
> We can use __skb_queue_head_init() instead of skb_queue_head_init()
> to make this more consistent.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
We should probably at some point try to make an sk_buff_head_lite
that only has the two pointers, so that we could shrink various
structures which have queues which we use like this.
^ permalink raw reply
* Re: [PATCH net] ipv6: don't install anycast address for /128 addresses on routers
From: David Miller @ 2014-01-06 21:33 UTC (permalink / raw)
To: hannes; +Cc: netdev, fx.lebail, thaller, jiri
In-Reply-To: <20140106165314.GC10204@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 6 Jan 2014 17:53:14 +0100
> It does not make sense to create an anycast address for an /128-prefix.
> Suppress it.
>
> As 32019e651c6fce ("ipv6: Do not leave router anycast address for /127
> prefixes.") shows we also may not leave them, because we could accidentally
> remove an anycast address the user has allocated or got added via another
> prefix.
>
> Cc: François-Xavier Le Bail <fx.lebail@yahoo.com>
> Cc: Thomas Haller <thaller@redhat.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] hso: fix handling of modem port SERIAL_STATE notifications
From: David Miller @ 2014-01-06 21:30 UTC (permalink / raw)
To: dcbw
Cc: hns, j.dumon, linux-usb, netdev, linux-kernel, marek.belisko,
e.verdonck
In-Reply-To: <1389024449.1866.3.camel@dcbw.local>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 06 Jan 2014 10:07:29 -0600
> The existing serial state notification handling expected older Option
> devices, having a hardcoded assumption that the Modem port was always
> USB interface #2. That isn't true for devices from the past few years.
>
> hso_serial_state_notification is a local cache of a USB Communications
> Interface Class SERIAL_STATE notification from the device, and the
> USB CDC specification (section 6.3, table 67 "Class-Specific Notifications")
> defines wIndex as the USB interface the event applies to. For hso
> devices this will always be the Modem port, as the Modem port is the
> only port which is set up to receive them by the driver.
>
> So instead of always expecting USB interface #2, instead validate the
> notification with the actual USB interface number of the Modem port.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Applied, although that BUG_ON() is a bit harsh. It might have been
cleaner to just dev_warn() ratelimited or similar and return.
^ permalink raw reply
* Re: [PATCH net-next] bonding: fix kstrtou8() return value verification in num_peer_notif
From: David Miller @ 2014-01-06 21:26 UTC (permalink / raw)
To: sfeldma; +Cc: vfalico, netdev, fubar, andy
In-Reply-To: <0E8BD1B8-4D60-4292-8694-CF0E988AA2BD@cumulusnetworks.com>
From: Scott Feldman <sfeldma@cumulusnetworks.com>
Date: Mon, 6 Jan 2014 09:02:18 -0800
> Acked-by: Scott Feldman <sfeldma@cumulusnetworks.com>--
Please put a newline at the end of your ACK next time so that
the posting footer doesn't become a part of it :-)
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] bonding: fix kstrtou8() return value verification in num_peer_notif
From: David Miller @ 2014-01-06 21:26 UTC (permalink / raw)
To: vfalico; +Cc: netdev, sfeldma, fubar, andy
In-Reply-To: <1389005680-9063-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Mon, 6 Jan 2014 11:54:40 +0100
> It returns 0 in case of success, !0 error otherwise. Fix the improper error
> verification.
>
> Fixes: 2c9839c143bbc ("bonding: add num_grat_arp attribute netlink support")
> CC: sfeldma@cumulusnetworks.com
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback
From: Florian Westphal @ 2014-01-06 21:23 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Florian Westphal, Andrey Vagin, netfilter-devel, netfilter,
coreteam, netdev, linux-kernel, vvs, Pablo Neira Ayuso,
Patrick McHardy, Jozsef Kadlecsik, David S. Miller
In-Reply-To: <20140106172130.GA2360@moon>
Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> On Mon, Jan 06, 2014 at 06:02:35PM +0100, Florian Westphal wrote:
> >
> > Can you elaborate?
> > Yes, nf_ct_is_dying(ct) might be called for the wrong conntrack.
> >
> > But, in case we _think_ that its the right one we call
> > nf_ct_tuple_equal() to verify we indeed found the right one:
> >
> > h = ____nf_conntrack_find(net, zone, tuple, hash);
> > if (h) { // might be released right now, but page won't go away (SLAB_BY_RCU)
> > ct = nf_ct_tuplehash_to_ctrack(h);
> > if (unlikely(nf_ct_is_dying(ct) ||
> > !atomic_inc_not_zero(&ct->ct_general.use)))
> > // which means we should hit this path (0 ref).
> > h = NULL;
> > else {
> > // otherwise, it cannot go away from under us, since
> > // we own a reference now.
> > if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple) ||
> > nf_ct_zone(ct) != zone)) {
> > // if we get here, the entry got recycled on other cpu
> > // for a different tuple, we can bail out and drop
> > // the reference safely and re-try the lookup
> > nf_ct_put(ct);
> > goto begin;
> > }
> > }
>
> I think tuple may match if
>
> task 1 task 2 task 3
> nf_conntrack_find_get
> ____nf_conntrack_find
> destroy_conntrack
> hlist_nulls_del_rcu
> nf_conntrack_free
> kmem_cache_free
> __nf_conntrack_alloc
> kmem_cache_alloc
> if (nf_ct_is_dying(ct))
>
> data is not yet cleaned
>
> memset(&ct->tuplehash[IP_CT_DIR_MAX],
>
> No? Or there something obvious I'm missing?
IMHO this isn't obvious at all :-)
But, in the example above, the atomic_inc_not_zero() should fail
until after __nf_conntrack_alloc() re-inits the refcount to 1.
The mb there should make sure ____nf_conntrack_find() doesn't
find an outdated tuple before this.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: Warn if device doesn't have enough PCI bandwidth
From: David Miller @ 2014-01-06 21:21 UTC (permalink / raw)
To: bhutchings; +Cc: amirv, jeffrey.t.kirsher, bhelgaas, netdev, ogerlitz, eyalpe
In-Reply-To: <1389042955.9947.110.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 6 Jan 2014 21:15:55 +0000
> We ought to have a generic PCI layer function that warns when a PCIe
> device is running below maximum link width/speed. Maybe even run it as
> soon as the device is enumerated, so that a driver doesn't need to do
> anything.
Agreed.
^ permalink raw reply
* Re: tx-nocache-copy performance
From: David Miller @ 2014-01-06 21:20 UTC (permalink / raw)
To: therbert; +Cc: bpoirier, netdev
In-Reply-To: <CA+mtBx_RH3v92Pmd_TYM=i0Anx-iG63762NPRSeCc1k98-Q6UQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 6 Jan 2014 12:59:59 -0800
> btw, I still believe it would be a win if we could use vmsplice to
> mitigate the copy altogether, unfortunately no one has yet to come up
> with an interface to reliably reclaim buffers :-(.
Indeed, this issue keeps coming up continually.
^ permalink raw reply
* Re: [PATCH net-next] net-gre-gro: Add GRE support to the GRO stack
From: David Miller @ 2014-01-06 21:18 UTC (permalink / raw)
To: hkchu; +Cc: edumazet, herbert, ogerlitz, netdev
In-Reply-To: <20140106.154330.1324356005311602000.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 06 Jan 2014 15:43:30 -0500 (EST)
> That the gre offload bits won't be registered unless GRE is enabled and
> initialized/loaded, right?
In fact, it's utterly and completely bogus to make only this change.
It breaks the build, I'm reverting:
ERROR: "gre_offload_exit" [net/ipv4/gre.ko] undefined!
ERROR: "gre_offload_init" [net/ipv4/gre.ko] undefined!
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: Warn if device doesn't have enough PCI bandwidth
From: Ben Hutchings @ 2014-01-06 21:15 UTC (permalink / raw)
To: Amir Vadai, Jeff Kirsher, Bjorn Helgaas
Cc: David S. Miller, netdev, Or Gerlitz, Eyal Perry
In-Reply-To: <1388863024-8718-1-git-send-email-amirv@mellanox.com>
On Sat, 2014-01-04 at 21:17 +0200, Amir Vadai wrote:
> From: Eyal Perry <eyalpe@mellanox.com>
>
> Check if the device get enough bandwidth from the entire PCI chain to satisfy
> its capabilities. This patch determines the PCIe device's bandwidth capabilities
> by reading its PCIe Link Capabilities registers and then call the
> pcie_get_minimum_link function to ensure that the adapter is hooked into a slot
> which is capable of providing the necessary bandwidth capabilities.
[...]
This is essentially another duplicate of what ixgbe and i40e are
doing... (And the out-of-tree version of sfc does it too, but I never
felt that was ready for in-tree.)
We ought to have a generic PCI layer function that warns when a PCIe
device is running below maximum link width/speed. Maybe even run it as
soon as the device is enumerated, so that a driver doesn't need to do
anything.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] adjust the code of r8152
From: David Miller @ 2014-01-06 21:15 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1388999323-9059-1-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 6 Jan 2014 17:08:40 +0800
> Replace some tabs and modify the return value of rtl_ops_init().
>
> v2: add the terminating newline for the message of patch #3.
Series applied.
^ permalink raw reply
* Re: tx-nocache-copy performance
From: Eric Dumazet @ 2014-01-06 21:13 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Tom Herbert, netdev
In-Reply-To: <1389041855.12212.210.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, 2014-01-06 at 12:57 -0800, Eric Dumazet wrote:
> We raised this point last year, for same reasons.
>
> http://www.spinics.net/lists/netdev/msg226501.html
>
> I agree we should revert the default.
>
> I'll post new perf data using latest net-next kernel and a bnx2x NIC.
Updated results with latest net-next :
(cpu is Intel(R) Xeon(R) CPU X5660 @ 2.80GHz)
lpq83:~# ./ethtool -K eth0 tx-nocache-copy on
lpq83:~# perf stat ./netperf -H lpq84 -c
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
87380 16384 16384 10.00 9407.44 2.50 -1.00 0.522 -1.000
Performance counter stats for './netperf -H lpq84 -c':
4282.648396 task-clock # 0.423 CPUs utilized
9,348 context-switches # 0.002 M/sec
88 CPU-migrations # 0.021 K/sec
355 page-faults # 0.083 K/sec
11,812,797,651 cycles # 2.758 GHz [82.79%]
9,020,522,817 stalled-cycles-frontend # 76.36% frontend cycles idle [82.54%]
4,579,889,681 stalled-cycles-backend # 38.77% backend cycles idle [67.33%]
6,053,172,792 instructions # 0.51 insns per cycle
# 1.49 stalled cycles per insn [83.64%]
597,275,583 branches # 139.464 M/sec [83.70%]
8,960,541 branch-misses # 1.50% of all branches [83.65%]
10.128990264 seconds time elapsed
lpq83:~# ./ethtool -K eth0 tx-nocache-copy off
lpq83:~# perf stat ./netperf -H lpq84 -c
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
87380 16384 16384 10.00 9412.45 2.15 -1.00 0.449 -1.000
Performance counter stats for './netperf -H lpq84 -c':
2847.375441 task-clock # 0.281 CPUs utilized
11,632 context-switches # 0.004 M/sec
49 CPU-migrations # 0.017 K/sec
354 page-faults # 0.124 K/sec
7,646,889,749 cycles # 2.686 GHz [83.34%]
6,115,050,032 stalled-cycles-frontend # 79.97% frontend cycles idle [83.31%]
1,726,460,071 stalled-cycles-backend # 22.58% backend cycles idle [66.55%]
2,079,702,453 instructions # 0.27 insns per cycle
# 2.94 stalled cycles per insn [83.22%]
363,773,213 branches # 127.757 M/sec [83.29%]
4,242,732 branch-misses # 1.17% of all branches [83.51%]
10.128449949 seconds time elapsed
^ permalink raw reply
* Re: [PATCH 3/4] tcp: metrics: Delete all entries matching a certain destination
From: David Miller @ 2014-01-06 21:10 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev, eric.dumazet, ja
In-Reply-To: <20140102091823.GA31178@cpaasch-mac>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Thu, 2 Jan 2014 10:18:23 +0100
> Do you mean that if no source-IP is given in the netlink command that all
> entries matching the dst should be deleted or rather only one of them (and that it
> would be non-deterministic which one)?
You would delete all of them, it's the only way to stay compatible with
the current code.
> Because, if I delete all of them, then "ip tcp_metrics flush PREFIX" of
> today's iproute2 will complain, because iproute2 expects that for each entry of
> "ip tcp_metrics show" a delete-call must be done.
>
> But, the non-deterministic case also feels a bit odd to me.
iproute2 should not expect that if it doesn't specify a specific
source address, in fact it doesn't even know how to currently. I
can't think of any other reasonable behavior.
^ 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