* [ofa-general] [PATCHES] TX batching rev2.5
From: jamal @ 2007-10-09 22:07 UTC (permalink / raw)
To: David Miller
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, kaber
Please provide feedback on the code and/or architecture.
They are now updated to work with the latest rebased net-2.6.24
from a few hours ago.
I am on travel mode so wont have time to do more testing for the next
few days - i do consider this to be stable at this point based on
what i have been testing (famous last words).
Patch 1: Introduces batching interface
Patch 2: Core uses batching interface
Patch 3: get rid of dev->gso_skb
What has changed since i posted last:
-------------------------------------
1) There was some cruft leftover from prep_frame feature that i forgot
to remove last time - it is now gone.
2) In the shower this AM, i realized that it is plausible that a
batch of packets sent to the driver may all be dropped because
they are badly formatted. Current drivers all return NETDEV_TX_OK
in all such cases. This will lead for us to call dev->hard_end_xmit()
to be invoked unnecessarily. I already had a NETDEV_TX_DROPPED within
batching drivers, so i made that global and make the batching drivers
return it if they drop packets. The core calls dev->hard_end_xmit()
when at least one packet makes it through.
Things i am gonna say that nobody will see (wink)
-------------------------------------------------
Dave please let me know if this meets your desires to allow devices
which are SG and able to compute CSUM benefit just in case i
misunderstood.
Herbert, if you can look at at least patch 3 i will appreaciate it
(since it kills dev->gso_skb that you introduced).
UPCOMING PATCHES
---------------
As before:
More patches to follow later if i get some feedback - i didnt want to
overload people by dumping too many patches. Most of these patches
mentioned below are ready to go; some need some re-testing and others
need a little porting from an earlier kernel:
- tg3 driver
- tun driver
- pktgen
- netiron driver
- e1000e driver (non-LLTX)
- ethtool interface
- There is at least one other driver promised to me
Theres also a driver-howto that i will post soon today.
PERFORMANCE TESTING
--------------------
System under test hardware is still a 2xdual core opteron with a
couple of tg3s.
A test tool generates udp traffic of different sizes for upto 60
seconds per run or a total of 30M packets. I have 4 threads each
running on a specific CPU which keep all the CPUs as busy as they can
sending packets targetted at a directly connected box's udp discard
port.
All 4 CPUs target a single tg3 to send. The receiving box has a tc rule
which counts and drops all incoming udp packets to discard port - this
allows me to make sure that the receiver is not the bottleneck in the
testing. Packet sizes sent are {8B, 32B, 64B, 128B, 256B, 512B, 1024B}.
Each packet size run is repeated 10 times to ensure that there are no
transients. The average of all 10 runs is then computed and collected.
I do plan also to run forwarding and TCP tests in the future when the
dust settles.
cheers,
jamal
^ permalink raw reply
* [PATCH] natsemi: Use NATSEMI_TIMER_FREQ consistently
From: Mark Brown @ 2007-10-09 21:57 UTC (permalink / raw)
To: jgarzik, thockin; +Cc: netdev, linux-kernel, Mark Brown
In-Reply-To: <1191967059-7143-1-git-send-email-broonie@sirena.org.uk>
The natsemi driver has a define NATSEMI_TIMER_FREQ which looks like it
controls the normal frequency of the chip poll timer but in fact only
takes effect for the first run of the timer. Adjust the value of the
define to match that used by the timer and use the define consistently.
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
---
drivers/net/natsemi.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 0b33a58..1f88604 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -108,7 +108,7 @@ static int full_duplex[MAX_UNITS];
#define TX_TIMEOUT (2*HZ)
#define NATSEMI_HW_TIMEOUT 400
-#define NATSEMI_TIMER_FREQ 3*HZ
+#define NATSEMI_TIMER_FREQ 5*HZ
#define NATSEMI_PG0_NREGS 64
#define NATSEMI_RFDR_NREGS 8
#define NATSEMI_PG1_NREGS 4
@@ -1797,7 +1797,7 @@ static void netdev_timer(unsigned long data)
struct net_device *dev = (struct net_device *)data;
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
- int next_tick = 5*HZ;
+ int next_tick = NATSEMI_TIMER_FREQ;
if (netif_msg_timer(np)) {
/* DO NOT read the IntrStatus register,
--
1.5.3.4
^ permalink raw reply related
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: jamal @ 2007-10-09 21:56 UTC (permalink / raw)
To: David Miller
Cc: johnpol, Robert.Olsson, herbert, gaagaan, jeff, rdreier,
peter.p.waskiewicz.jr, mcarlson, andi, general, netdev, tgraf,
randy.dunlap, sri, shemminger, kaber, mchan, jagana
In-Reply-To: <20071009.142235.74385364.davem@davemloft.net>
On Tue, 2007-09-10 at 14:22 -0700, David Miller wrote:
> Even if the device has "huge queues" I still think we need a software
> queue for when the hardware one backs up.
It should be fine to just "pretend" the qdisc exists despite it sitting
in the driver and not have s/ware queues at all to avoid all the
challenges that qdiscs bring;
if the h/ware queues are full because of link pressure etc, you drop. We
drop today when the s/ware queues are full. The driver txmit lock takes
place of the qdisc queue lock etc. I am assuming there is still need for
that locking. The filter/classification scheme still works as is and
select classes which map to rings. tc still works as is etc.
cheers,
jamal
^ 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
* 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: [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: 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: [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: 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: 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: [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 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: 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 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: [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 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 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 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 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 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
* [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
* [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
* 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
* 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][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
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