* RE: [PATCH 2/3][NET_BATCH] net core use batching
From: Waskiewicz Jr, Peter P @ 2007-10-09 19:07 UTC (permalink / raw)
To: Jeff Garzik
Cc: David Miller, hadi, krkumar2, johnpol, herbert, kaber, shemminger,
jagana, Robert.Olsson, rick.jones2, xma, gaagaan, netdev, rdreier,
mcarlson, mchan, general, tgraf, randy.dunlap, sri
In-Reply-To: <470BD0B7.4070607@garzik.org>
> A misunderstanding, I think.
>
> To my brain, DaveM's item #2 seemed to assume/require the NIC
> hardware to balance fairly across hw TX rings, which seemed
> to preclude the
> 8139cp/tg3 style of strict-prio hardware. That's what I was
> responding to.
>
> As long as there is some modular way to fit 8139cp/tg3 style
> multi-TX into our universe, I'm happy :)
Ah hah. Yes, a misunderstanding on my part. Thanks for the
clarification. Methinks more caffeine is required for today...
-PJ
^ permalink raw reply
* Re: [PATCH][NETNS] Don't memset() netns to zero manually
From: David Miller @ 2007-10-09 20:02 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <470B6A83.8070600@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 15:48:19 +0400
> The newly created net namespace is set to 0 with memset()
> in setup_net(). The setup_net() is also called for the
> init_net_ns(), which is zeroed naturally as a global var.
>
> So remove this memset and allocate new nets with the
> kmem_cache_zalloc().
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel!
^ permalink raw reply
* Re: [PATCH][NETNS] Make ifindex generation per-namespace
From: David Miller @ 2007-10-09 20:11 UTC (permalink / raw)
To: ebiederm; +Cc: dlstevens, xemul, devel, netdev, netdev-owner
In-Reply-To: <m1k5pwxjxd.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 09 Oct 2007 11:43:58 -0600
> David Stevens <dlstevens@us.ibm.com> writes:
>
> > Sorry if this is a dumb question, but what is the model you intend for
> > SNMP? Do you want each namespace to be its own virtual machine with
> > its own, separate MIB?
>
> Each network namespace appears to user space as a completely separate
> network stack. So yes a separate instance of the MIB is appropriate.
We don't think you can validly do that, as David tried to explain.
The interface indexes are visible remotely to remote SNMP querying
applications. They have to be unique within the physical system.
^ permalink raw reply
* Re: [PATCH][NETNS] Make ifindex generation per-namespace
From: David Miller @ 2007-10-09 20:12 UTC (permalink / raw)
To: dlstevens; +Cc: xemul, devel, ebiederm, netdev, netdev-owner
In-Reply-To: <OF54650AF1.A1051792-ON8825736F.00588F0B-8825736F.00597D24@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 9 Oct 2007 09:18:25 -0700
> Ifindex's have to uniquely identify the interface (virtual or
> otherwise) to remote queriers (not just local applications), so
> unless you pay the price of separating all the SNMP MIBs per
> namespace too, it seems you'll need some way to remap these for SNMP
> queries, right?
I don't see how it can work even with per-namespace MIBs,
the interface indexes have to be unique per "system".
^ permalink raw reply
* Re: [PATCH][NETNS] Make ifindex generation per-namespace
From: David Miller @ 2007-10-09 20:12 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, ebiederm
In-Reply-To: <470B71CD.3000706@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 16:19:25 +0400
> Currently indexes for netdevices come sequentially one by
> one, and the same stays true even for devices that are
> created for namespaces.
>
> Side effects of this are:
> * lo device has not 1 index in a namespace. This may break
> some userspace that relies on it (and AFAIR something
> really broke in OpenVZ VEs without this);
> * after some time namespaces will have devices with indexes
> like 1000000 os similar. This might be confusing for a
> human (tools will not mind).
>
> So move the (currently "global" and static) ifindex variable
> on the struct net, making the indexes allocation look more
> like on a standalone machine.
>
> Moreover - when we have indexes intersect between namespaces,
> we may catch more BUGs in the future related to "wrong device
> was found for a given index".
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Based upon Eric's and other's comments, I'm holding off on
this for now.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 20:14 UTC (permalink / raw)
To: jeff
Cc: krkumar2, gaagaan, general, hadi, herbert, jagana, johnpol, kaber,
mcarlson, mchan, netdev, peter.p.waskiewicz.jr, randy.dunlap,
rdreier, rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
In-Reply-To: <470B77A9.600@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 09 Oct 2007 08:44:25 -0400
> David Miller wrote:
> > From: Krishna Kumar2 <krkumar2@in.ibm.com>
> > Date: Tue, 9 Oct 2007 16:51:14 +0530
> >
> >> David Miller <davem@davemloft.net> wrote on 10/09/2007 04:32:55 PM:
> >>
> >>> Ignore LLTX, it sucks, it was a big mistake, and we will get rid of
> >>> it.
> >> Great, this will make life easy. Any idea how long that would take?
> >> It seems simple enough to do.
> >
> > I'd say we can probably try to get rid of it in 2.6.25, this is
> > assuming we get driver authors to cooperate and do the conversions
> > or alternatively some other motivated person.
> >
> > I can just threaten to do them all and that should get the driver
> > maintainers going :-)
>
> What, like this? :)
Thanks, but it's probably going to need some corrections and/or
an audit.
If you unconditionally take those locks in the transmit function,
there is probably an ABBA deadlock elsewhere in the driver now, most
likely in the TX reclaim processing, and you therefore need to handle
that too.
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Jeff Garzik @ 2007-10-09 20:20 UTC (permalink / raw)
To: David Miller
Cc: jagana, herbert, gaagaan, Robert.Olsson, mcarlson, rdreier,
peter.p.waskiewicz.jr, hadi, netdev, general, mchan, tgraf,
randy.dunlap, johnpol, shemminger, kaber, sri
In-Reply-To: <20071009.131438.74562715.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Tue, 09 Oct 2007 08:44:25 -0400
>
>> David Miller wrote:
>>> From: Krishna Kumar2 <krkumar2@in.ibm.com>
>>> Date: Tue, 9 Oct 2007 16:51:14 +0530
>>>
>>>> David Miller <davem@davemloft.net> wrote on 10/09/2007 04:32:55 PM:
>>>>
>>>>> Ignore LLTX, it sucks, it was a big mistake, and we will get rid of
>>>>> it.
>>>> Great, this will make life easy. Any idea how long that would take?
>>>> It seems simple enough to do.
>>> I'd say we can probably try to get rid of it in 2.6.25, this is
>>> assuming we get driver authors to cooperate and do the conversions
>>> or alternatively some other motivated person.
>>>
>>> I can just threaten to do them all and that should get the driver
>>> maintainers going :-)
>> What, like this? :)
>
> Thanks, but it's probably going to need some corrections and/or
> an audit.
I would be happy if someone wanted to audit that patch.
> If you unconditionally take those locks in the transmit function,
> there is probably an ABBA deadlock elsewhere in the driver now, most
> likely in the TX reclaim processing, and you therefore need to handle
> that too.
And I most certainly checked the relevant transmit paths and other
locking to make sure lock ordering was correct.
Jeff
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Roland Dreier @ 2007-10-09 20:22 UTC (permalink / raw)
To: David Miller
Cc: jagana, herbert, gaagaan, Robert.Olsson, mcarlson,
peter.p.waskiewicz.jr, hadi, randy.dunlap, jeff, general, mchan,
tgraf, netdev, johnpol, shemminger, kaber, sri
In-Reply-To: <20071009.042441.30182968.davem@davemloft.net>
> I'd say we can probably try to get rid of it in 2.6.25, this is
> assuming we get driver authors to cooperate and do the conversions
> or alternatively some other motivated person.
>
> I can just threaten to do them all and that should get the driver
> maintainers going :-)
I can definitely kill LLTX for IPoIB by 2.6.25 and I just added it to
my TODO list so I don't forget.
In fact if 2.6.23 drags on long enough I may do it for 2.6.24....
^ permalink raw reply
* Re: [PATCH 1/7] [IPSEC]: Remove bogus ref count in xfrm_secpath_reject
From: David Miller @ 2007-10-09 20:24 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCF-0005Lh-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:31 +0800
> [IPSEC]: Remove bogus ref count in xfrm_secpath_reject
>
> Constructs of the form
>
> xfrm_state_hold(x);
> foo(x);
> xfrm_state_put(x);
>
> tend to be broken because foo is either synchronous where this is totally
> unnecessary or if foo is asynchronous then the reference count is in the
> wrong spot.
>
> In the case of xfrm_secpath_reject, the function is synchronous and therefore
> we should just kill the reference count.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/7] [IPSEC]: Store IPv6 nh pointer in mac_header on output
From: David Miller @ 2007-10-09 20:26 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCG-0005Lp-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:32 +0800
> [IPSEC]: Store IPv6 nh pointer in mac_header on output
>
> Current the x->mode->output functions store the IPv6 nh pointer in the
> skb network header. This is inconvenient because the network header then
> has to be fixed up before the packet can leave the IPsec stack. The mac
> header field is unused on output so we can use that to store this instead.
>
> This patch does that and removes the network header fix-up in xfrm_output.
>
> It also uses ipv6_hdr where appropriate in the x->type->output functions.
>
> There is also a minor clean-up in esp4 to make it use the same code as
> esp6 to help any subsequent effort to merge the two.
>
> Lastly it kills two redundant skb_set_* statements in BEET that were
> simply copied over from transport mode.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 3/7] [IPSEC]: Remove gratuitous km wake-up events on ACQUIRE
From: David Miller @ 2007-10-09 20:27 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCH-0005Lx-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:33 +0800
> [IPSEC]: Remove gratuitous km wake-up events on ACQUIRE
>
> There is no point in waking people up when creating/updating larval states
> because they'll just go back to sleep again as larval states by definition
> cannot be found by xfrm_state_find.
>
> We should only wake them up when the larvals mature or die.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 4/7] [IPSEC]: Move common code into xfrm_alloc_spi
From: David Miller @ 2007-10-09 20:30 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCI-0005M5-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:34 +0800
> [IPSEC]: Move common code into xfrm_alloc_spi
>
> This patch moves some common code that conceptually belongs to the xfrm core
> from af_key/xfrm_user into xfrm_alloc_spi.
>
> In particular, the spin lock on the state is now taken inside xfrm_alloc_spi.
> Previously it also protected the construction of the response PF_KEY/XFRM
> messages to user-space. This is inconsistent as other identical constructions
> are not protected by the state lock. This is bad because they in fact should
> be protected but only in certain spots (so as not to hold the lock for too
> long which may cause packet drops).
>
> The SPI byte order conversion has also been moved.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 5/7] [XFRM] user: Move attribute copying code into copy_to_user_state_extra
From: David Miller @ 2007-10-09 20:31 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCJ-0005MD-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:35 +0800
> [XFRM] user: Move attribute copying code into copy_to_user_state_extra
>
> Here's a good example of code duplication leading to code rot. The
> notification patch did its own netlink message creation for xfrm states.
> It duplicated code that was already in dump_one_state. Guess what, the
> next time (and the time after) when someone updated dump_one_state the
> notification path got zilch.
>
> This patch moves that code from dump_one_state to copy_to_user_state_extra
> and uses it in xfrm_notify_sa too. Unfortunately whoever updates this
> still needs to update xfrm_sa_len since the notification path wants to
> know the exact size for allocation.
>
> At least I've added a comment saying so and if someone still forgest, we'll
> have a WARN_ON telling us so.
>
> I also changed the security size calculation to use xfrm_user_sec_ctx since
> that's what we actually put into the skb. However it makes no practical
> difference since it has the same size as xfrm_sec_ctx.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 6/7] [IPSEC]: Lock state when copying non-atomic fields to user-space
From: David Miller @ 2007-10-09 20:33 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCK-0005ML-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:36 +0800
> [IPSEC]: Lock state when copying non-atomic fields to user-space
>
> This patch adds locking so that when we're copying non-atomic fields such as
> life-time or coaddr to user-space we don't get a partial result.
>
> For af_key I've changed every instance of pfkey_xfrm_state2msg apart from
> expiration notification to include the keys and life-times. This is in-line
> with XFRM behaviour.
>
> The actual cases affected are:
>
> * pfkey_getspi: No change as we don't have any keys to copy.
> * key_notify_sa:
> + ADD/UPD: This wouldn't work otherwise.
> + DEL: It can't hurt.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
I would be more careful with the changelog description for
something like this in the future. It sounds like this
patch will cause us to touch userspace with locks held,
which obviously only works in very limited scenerios
and is usually a BUG.
But you're actually just constructing SKB response netlink
bits, which later will be copied into userspace but long
after we've released these locks.
^ permalink raw reply
* Re: [PATCH 7/7] [IPSEC]: Move state lock into x->type->output
From: David Miller @ 2007-10-09 20:33 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1IfGCL-0005MT-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:37 +0800
> [IPSEC]: Move state lock into x->type->output
>
> This patch releases the lock on the state before calling x->type->output.
> It also adds the lock to the spots where they're currently needed.
>
> Most of those places (all except mip6) are expected to disappear with
> async crypto.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 20:43 UTC (permalink / raw)
To: andi
Cc: johnpol, Robert.Olsson, herbert, gaagaan, shemminger, netdev,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, randy.dunlap, jagana, kaber, sri
In-Reply-To: <p73k5pw44ew.fsf@bingen.suse.de>
From: Andi Kleen <andi@firstfloor.org>
Date: 09 Oct 2007 18:51:51 +0200
> Hopefully that new qdisc will just use the TX rings of the hardware
> directly. They are typically large enough these days. That might avoid
> some locking in this critical path.
Indeed, I also realized last night that for the default qdiscs
we do a lot of stupid useless work. If the queue is a FIFO
and the device can take packets, we should send it directly
and not stick it into the qdisc at all.
> If the data is just passed on to the hardware queue, why is any
> locking needed at all? (except for the driver locking of course)
Absolutely.
Our packet scheduler subsystem is great, but by default it should just
get out of the way.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 20:51 UTC (permalink / raw)
To: rdreier
Cc: krkumar2, gaagaan, general, hadi, herbert, jagana, jeff, johnpol,
kaber, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rick.jones2, Robert.Olsson, shemminger, sri, tgraf,
xma
In-Reply-To: <ada3awkhwbv.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Tue, 09 Oct 2007 13:22:44 -0700
> I can definitely kill LLTX for IPoIB by 2.6.25 and I just added it to
> my TODO list so I don't forget.
>
> In fact if 2.6.23 drags on long enough I may do it for 2.6.24....
Before you add new entries to your list, how is that ibm driver NAPI
conversion coming along? :-)
Right now that's a more pressing task to complete.
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Stephen Hemminger @ 2007-10-09 20:53 UTC (permalink / raw)
To: David Miller
Cc: johnpol, Robert.Olsson, herbert, gaagaan, jeff, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, andi, general, netdev,
tgraf, randy.dunlap, jagana, kaber, mchan, sri
In-Reply-To: <20071009.134331.35664207.davem@davemloft.net>
On Tue, 09 Oct 2007 13:43:31 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Andi Kleen <andi@firstfloor.org>
> Date: 09 Oct 2007 18:51:51 +0200
>
> > Hopefully that new qdisc will just use the TX rings of the hardware
> > directly. They are typically large enough these days. That might avoid
> > some locking in this critical path.
>
> Indeed, I also realized last night that for the default qdiscs
> we do a lot of stupid useless work. If the queue is a FIFO
> and the device can take packets, we should send it directly
> and not stick it into the qdisc at all.
>
> > If the data is just passed on to the hardware queue, why is any
> > locking needed at all? (except for the driver locking of course)
>
> Absolutely.
>
> Our packet scheduler subsystem is great, but by default it should just
> get out of the way.
I was thinking why not have a default transmit queue len of 0 like
the virtual devices.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH][NETNS] Make ifindex generation per-namespace
From: Eric W. Biederman @ 2007-10-09 21:00 UTC (permalink / raw)
To: David Miller; +Cc: dlstevens, xemul, devel, netdev, netdev-owner
In-Reply-To: <20071009.131113.112622864.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Tue, 09 Oct 2007 11:43:58 -0600
>
>> David Stevens <dlstevens@us.ibm.com> writes:
>>
>> > Sorry if this is a dumb question, but what is the model you intend for
>> > SNMP? Do you want each namespace to be its own virtual machine with
>> > its own, separate MIB?
>>
>> Each network namespace appears to user space as a completely separate
>> network stack. So yes a separate instance of the MIB is appropriate.
>
> We don't think you can validly do that, as David tried to explain.
>
> The interface indexes are visible remotely to remote SNMP querying
> applications. They have to be unique within the physical system.
I think figuring out what we are doing with SNMP is not any harder
or easier then any other user space interface, and like I said I
don't think we are ready yet.
>From the perspective of monitoring network namespaces make the entire
system looks more like a cluster then it does a single machine, and
that is how I would look at portraying the system to SNMP if I had to
do that work today. A switch with a bunch of different machines
behind it. Especially in the context of container migration this
becomes an attractive model.
Regardless it is early yet and there is plenty of time to revisit this
after we solved the easier and less controversial problems.
Eric
^ permalink raw reply
* Re: net-2.6.24 rebased...
From: Urs Thuermann @ 2007-10-09 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, akpm, oliver
In-Reply-To: <20071009.024108.59465259.davem@davemloft.net>
Hallo Dave,
> 9.1MB, 739 changesets, keep those patches flowing!
Last week I have sent another version of our patch series for PF_CAN.
The changes after the last review feedback were only cosmetics.
Do you have any plans with that code for this or the next release?
Regards,
urs
^ permalink raw reply
* Re: [PATCH][NETNS] Make ifindex generation per-namespace
From: David Miller @ 2007-10-09 21:17 UTC (permalink / raw)
To: ebiederm; +Cc: dlstevens, xemul, devel, netdev, netdev-owner
In-Reply-To: <m1tzp0vw9x.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 09 Oct 2007 15:00:10 -0600
> Regardless it is early yet and there is plenty of time to revisit this
> after we solved the easier and less controversial problems.
Ok.
I would encourage you to learn how the SNMP mibs work, and whether
they associate things with interfaces and/or unique MAC addresses.
The semantics may have conflicts with your envisioned cluster
abstraction.
^ permalink raw reply
* Re: net-2.6.24 rebased...
From: David Miller @ 2007-10-09 21:18 UTC (permalink / raw)
To: urs; +Cc: netdev, akpm, oliver
In-Reply-To: <ygfbqb8dm9l.fsf@janus.isnogud.escape.de>
From: Urs Thuermann <urs@isnogud.escape.de>
Date: 09 Oct 2007 23:13:42 +0200
> Last week I have sent another version of our patch series for PF_CAN.
> The changes after the last review feedback were only cosmetics.
>
> Do you have any plans with that code for this or the next release?
I think PF_CAN will go in 2.6.25
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 21:22 UTC (permalink / raw)
To: shemminger
Cc: johnpol, Robert.Olsson, herbert, gaagaan, jeff, rdreier,
peter.p.waskiewicz.jr, hadi, mcarlson, andi, general, netdev,
tgraf, randy.dunlap, jagana, kaber, mchan, sri
In-Reply-To: <20071009135340.33e5922c@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 9 Oct 2007 13:53:40 -0700
> I was thinking why not have a default transmit queue len of 0 like
> the virtual devices.
I'm not so sure.
Even if the device has "huge queues" I still think we need a software
queue for when the hardware one backs up.
It is even beneficial to stick with reasonably sized TX queues because
it keeps the total resident state accessed by the CPU within the
bounds of the L2 cache. If you go past that it actually hurts to make
the TX queue larger instead of helps even if it means you never hit
back pressure.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-09 21:25 UTC (permalink / raw)
To: jeff
Cc: krkumar2, gaagaan, general, hadi, herbert, jagana, johnpol, kaber,
mcarlson, mchan, netdev, peter.p.waskiewicz.jr, randy.dunlap,
rdreier, rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
In-Reply-To: <470BE27E.4000101@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 09 Oct 2007 16:20:14 -0400
> David Miller wrote:
> > If you unconditionally take those locks in the transmit function,
> > there is probably an ABBA deadlock elsewhere in the driver now, most
> > likely in the TX reclaim processing, and you therefore need to handle
> > that too.
>
> And I most certainly checked the relevant transmit paths and other
> locking to make sure lock ordering was correct.
Awesome.
^ permalink raw reply
* Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Roland Dreier @ 2007-10-09 21:40 UTC (permalink / raw)
To: David Miller
Cc: krkumar2, gaagaan, general, hadi, herbert, jagana, jeff, johnpol,
kaber, mcarlson, mchan, netdev, peter.p.waskiewicz.jr,
randy.dunlap, rick.jones2, Robert.Olsson, shemminger, sri, tgraf,
xma
In-Reply-To: <20071009.135145.95506679.davem@davemloft.net>
> Before you add new entries to your list, how is that ibm driver NAPI
> conversion coming along? :-)
I still haven't done much. OK, I will try to get my board booting
again this week.
^ 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