* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Robert P. J. Day @ 2007-07-20 13:04 UTC (permalink / raw)
To: Gabriel C; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <46A0AB44.70009@googlemail.com>
On Fri, 20 Jul 2007, Gabriel C wrote:
> Robert P. J. Day wrote:
> > this has *nothing* to do with the aforementioned maturity levels.
> > i understand entirely the inconsistency above. what i'm
> > suggesting is that it might very well be more appropriate to *drop
> > the dependency* rather than munge the prompt to add the qualifier.
>
> This is a thing the author/maintainer/subsystem maintainer should and need do.
>
> They know when something is not EXPERIMENTAL anymore.
agreed (sort of). all i'm saying (and after this, i'll shut the heck
up about it) is that, if you find a Kconfig entry of the form:
config FUBAR
prompt "whatever"
depends on ... && EXPERIMENTAL
and you want to make that selection consistent, you have two
possibilities:
1) add "(EXPERIMENTAL)" to the prompt to match the dependency, or
2) drop the dependency on EXPERIMENTAL to match the prompt
i contend that, *for now*, it's a better investment in time to find
entries like that that are *clearly* not experimental any more, and
drop the dependency. not only will that make it consistent, but it's
unlikely that you'll ever have to *revert* that decision.
OTOH, it's quite possible that, after you add the prompt suffix of
"(EXPERIMENTAL)" for consistency, the feature maintainer might come by
tomorrow and say something like, "nah, that feature's been around for
years, it's as stable as it gets," and will undo the patch you just
made, wasting your time and effort.
lastly, i'm not convinced that it's *only* the feature maintainer
that can make that decision. surely, there's enough clever people
here who can look at any given feature and say, "yeah, i've been using
that for years, it's rock solid, it's stupid to keep that dependent on
EXPERIMENTAL."
all i'm saying is, if you want to put some time in here, it's better
invested in *removing* what are clearly ridiculous dependencies on
EXPERIMENTAL, rather than *adding* even more of that labelling to the
tree.
rday
p.s. even if a given Kconfig entry *is* consistent, as in:
config SNAFU
bool "... (EXPERIMENTAL)"
depends on ... && EXPERIMENTAL
...
it's clear that there's a pile of *that* stuff for which all
references to EXPERIMENTAL can be dropped. all in all, given the
possible cleanup here, i'm thinking that going in and *adding* more
EXPERIMENTAL clutter to the Kconfig files is going in exactly the
wrong direction.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* [ofa-general] Re: [PATCH 00/10] Implement batching skb API
From: Krishna Kumar2 @ 2007-07-20 13:02 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: jagana, mcarlson, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, kaber, jeff, general, mchan,
tgraf, netdev, davem, sri
In-Reply-To: <20070720125423.GB13468@2ka.mipt.ru>
Hi Evgeniy,
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote on 07/20/2007 06:24:23 PM:
> > After fine-tuning qdisc and other changes, I modified IPoIB to use this
API,
> > and now get good gains. Summary for TCP & No Delay: 1 process improves
for
> > all cases from 1.4% to 49.5%; 4 process has almost identical
improvements
> > from -1.7% to 59.1%; 16 process case also improves in the range of
-1.2% to
> > 33.4%; while 64 process doesn't have much improvement (-3.3% to 12.4%).
UDP
> > was tested with 1 process netperf with small increase in BW but big
> > improvement in Service Demand. Netperf latency tests show small drop in
> > transaction rate (results in separate attachment).
>
> What about round-robin tcp time and latency test? In theory such batching
> mode should not change that timings, but practice can show new aspects.
> I will review code later this week (likely tomorrow) and if there will
> be some issues return back.
I had run RR test quite some time back and don't have the result at this
time,
other than remembering it was almost the same as the original. As I am
running
some tests on those systems at this time, I can send the results of RR
tomorrow.
Thanks,
- KK
^ permalink raw reply
* [ofa-general] Re: [PATCH 00/10] Implement batching skb API
From: Evgeniy Polyakov @ 2007-07-20 12:54 UTC (permalink / raw)
To: Krishna Kumar
Cc: jagana, Robert.Olsson, herbert, gaagaan, kumarkr, rdreier,
peter.p.waskiewicz.jr, mcarlson, kaber, jeff, general, mchan,
tgraf, netdev, sri, hadi, davem
In-Reply-To: <20070720063149.26341.84076.sendpatchset@localhost.localdomain>
Hi Krishna.
On Fri, Jul 20, 2007 at 12:01:49PM +0530, Krishna Kumar (krkumar2@in.ibm.com) wrote:
> After fine-tuning qdisc and other changes, I modified IPoIB to use this API,
> and now get good gains. Summary for TCP & No Delay: 1 process improves for
> all cases from 1.4% to 49.5%; 4 process has almost identical improvements
> from -1.7% to 59.1%; 16 process case also improves in the range of -1.2% to
> 33.4%; while 64 process doesn't have much improvement (-3.3% to 12.4%). UDP
> was tested with 1 process netperf with small increase in BW but big
> improvement in Service Demand. Netperf latency tests show small drop in
> transaction rate (results in separate attachment).
What about round-robin tcp time and latency test? In theory such batching
mode should not change that timings, but practice can show new aspects.
I will review code later this week (likely tomorrow) and if there will
be some issues return back.
--
Evgeniy Polyakov
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Patrick McHardy @ 2007-07-20 12:37 UTC (permalink / raw)
To: Krishna Kumar2
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <OF5FB5DB1E.711307CE-ON6525731E.0043AC4C-6525731E.00443C1B@in.ibm.com>
Krishna Kumar2 wrote:
> Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 04:50:37 PM:
>
>
>> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
>> If you'd use it for gso_skb it would come down to 8 bytes. struct
>> net_device is a pig already, and there are better ways to reduce this
>> than starting to allocating single members with a few bytes IMO.
>>
>
> Currently, this allocated pointer is an indication to let kernel users
> (qdisc_restart, setting/resetting tx_batch_skbs) know whether batching
> is enabled or disabled. Removing the pointer and making it static means
> those users cannot figure out this information . Adding another field to
> netdev may be a bad idea, so I am thinking of overloading dev->features
> to add a new flag (other than NETIF_F_BATCH_SKBS, since that is a driver
> capabilities flag) which can be set/cleared based on NETIF_F_BATCH_SKBS
> bit. Does this approach sound OK ?
>
I guess so. It would be more consistent with things like HW checksumming
etc. though to handle this through ethtool and have the ethtool callbacks
set or clear just the one feature bit. That would mean you don't need
to provide further indication of the device's capabilities to the stack
since only the driver enables or disables the feature.
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Krishna Kumar2 @ 2007-07-20 12:33 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
(My Notes crashed when I hit the Send button, so not sure if this went
out).
__________________
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 04:50:37 PM:
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes. struct
> net_device is a pig already, and there are better ways to reduce this
> than starting to allocating single members with a few bytes IMO.
Currently, this allocated pointer is an indication to let kernel users
(qdisc_restart, setting/resetting tx_batch_skbs) know whether batching
is enabled or disabled. Removing the pointer and making it static means
those users cannot figure out this information . Adding another field to
netdev may be a bad idea, so I am thinking of overloading dev->features
to add a new flag (other than NETIF_F_BATCH_SKBS, since that is a driver
capabilities flag) which can be set/cleared based on NETIF_F_BATCH_SKBS
bit. Does this approach sound OK ?
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Gabriel C @ 2007-07-20 12:32 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <Pine.LNX.4.64.0707200818010.12187@localhost.localdomain>
Robert P. J. Day wrote:
> On Fri, 20 Jul 2007, Gabriel C wrote:
>
>> Robert P. J. Day wrote:
>>> On Fri, 20 Jul 2007, Gabriel C wrote:
>>>
>>>> Hi,
>>>>
>>>> IP_VS has :
>>>>
>>>> ..
>>>>
>>>> tristate "IP virtual server support (EXPERIMENTAL)"
>>>>
>>>> ..
>>>>
>>>> but it does not depend on EXPERIMENTAL.
>>>>
>>>>
>>>> Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
>>>>
>>>> ---
>>>>
>>>> net/ipv4/ipvs/Kconfig | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig
>>>> index 09d0c3f..3c594ec 100644
>>>> --- a/net/ipv4/ipvs/Kconfig
>>>> +++ b/net/ipv4/ipvs/Kconfig
>>>> @@ -3,7 +3,7 @@
>>>> #
>>>> menuconfig IP_VS
>>>> tristate "IP virtual server support (EXPERIMENTAL)"
>>>> - depends on NETFILTER
>>>> + depends on NETFILTER && EXPERIMENTAL
>>>> ---help---
>>>> IP Virtual Server support will let you build a high-performance
>>>> virtual server based on cluster of two or more real servers. This
>>> there's maturity-level inconsistency like that in a few places, like
>>> when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE:
>>>
>> [ a lot examples ]
>>
>> I know that and there are a lot more things depending on
>> 'EXPERIMENTAL' and not having EXPERIMENTAL visible all over the tree
>> but that patch I've made for the _net_ part got NACK'ed while your
>> maturity idea and I rm -rf'ed all the other.
>>
>> This one has a missing depends on EXPERIMENTAL while saying it is.
>>
>> So *could* we please stop this maturity stuff for now ? I don't see
>> it in .23 nor .24 if at all.
>
> this has *nothing* to do with the aforementioned maturity levels. i
> understand entirely the inconsistency above. what i'm suggesting is
> that it might very well be more appropriate to *drop the dependency*
> rather than munge the prompt to add the qualifier.
This is a thing the author/maintainer/subsystem maintainer should and need do.
They know when something is not EXPERIMENTAL anymore.
>
> i think it's safe to say that there's *piles* of stuff in the Kconfig
> files that is still saddled with an EXPERIMENTAL dependency that's
> been around for years and has stabilized nicely.
I agree with you , there may be a lot things are marked EXPERIMENTAL but aren't anymore.
>i mean, seriously,
> is IP virtual server support still "experimental" in any way?
>
> rday
Gabriel
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Krishna Kumar2 @ 2007-07-20 12:25 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <46A09A85.7020500@trash.net>
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 04:50:37 PM:
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes. struct
> net_device is a pig already, and there are better ways to reduce this
> than starting to allocating single members with a few bytes IMO.
Currently, this allocated pointer is an indication to let kernel users
(qdisc_restart, setting/resetting tx_batch_skbs) know whether batching
is enabled or disabled. Removing the pointer and making it static means
those users cannot figure out this information . Adding another field to
netdev may be a bad idea, so I am thinking of overloading dev->features
to add a new flag (other than NETIF_F_BATCH_SKBS, since that is a driver
capabilities flag) which can be set/cleared based on NETIF_F_BATCH_SKBS
bit. Does this approach sound OK ?
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Robert P. J. Day @ 2007-07-20 12:21 UTC (permalink / raw)
To: Gabriel C; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <46A0A7C2.3090006@googlemail.com>
On Fri, 20 Jul 2007, Gabriel C wrote:
> Robert P. J. Day wrote:
> > On Fri, 20 Jul 2007, Gabriel C wrote:
> >
> >> Hi,
> >>
> >> IP_VS has :
> >>
> >> ..
> >>
> >> tristate "IP virtual server support (EXPERIMENTAL)"
> >>
> >> ..
> >>
> >> but it does not depend on EXPERIMENTAL.
> >>
> >>
> >> Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
> >>
> >> ---
> >>
> >> net/ipv4/ipvs/Kconfig | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig
> >> index 09d0c3f..3c594ec 100644
> >> --- a/net/ipv4/ipvs/Kconfig
> >> +++ b/net/ipv4/ipvs/Kconfig
> >> @@ -3,7 +3,7 @@
> >> #
> >> menuconfig IP_VS
> >> tristate "IP virtual server support (EXPERIMENTAL)"
> >> - depends on NETFILTER
> >> + depends on NETFILTER && EXPERIMENTAL
> >> ---help---
> >> IP Virtual Server support will let you build a high-performance
> >> virtual server based on cluster of two or more real servers. This
> >
> > there's maturity-level inconsistency like that in a few places, like
> > when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE:
> >
> [ a lot examples ]
>
> I know that and there are a lot more things depending on
> 'EXPERIMENTAL' and not having EXPERIMENTAL visible all over the tree
> but that patch I've made for the _net_ part got NACK'ed while your
> maturity idea and I rm -rf'ed all the other.
>
> This one has a missing depends on EXPERIMENTAL while saying it is.
>
> So *could* we please stop this maturity stuff for now ? I don't see
> it in .23 nor .24 if at all.
this has *nothing* to do with the aforementioned maturity levels. i
understand entirely the inconsistency above. what i'm suggesting is
that it might very well be more appropriate to *drop the dependency*
rather than munge the prompt to add the qualifier.
i think it's safe to say that there's *piles* of stuff in the Kconfig
files that is still saddled with an EXPERIMENTAL dependency that's
been around for years and has stabilized nicely. i mean, seriously,
is IP virtual server support still "experimental" in any way?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Gabriel C @ 2007-07-20 12:17 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <Pine.LNX.4.64.0707200753300.10966@localhost.localdomain>
Robert P. J. Day wrote:
> On Fri, 20 Jul 2007, Gabriel C wrote:
>
>> Hi,
>>
>> IP_VS has :
>>
>> ..
>>
>> tristate "IP virtual server support (EXPERIMENTAL)"
>>
>> ..
>>
>> but it does not depend on EXPERIMENTAL.
>>
>>
>> Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
>>
>> ---
>>
>> net/ipv4/ipvs/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig
>> index 09d0c3f..3c594ec 100644
>> --- a/net/ipv4/ipvs/Kconfig
>> +++ b/net/ipv4/ipvs/Kconfig
>> @@ -3,7 +3,7 @@
>> #
>> menuconfig IP_VS
>> tristate "IP virtual server support (EXPERIMENTAL)"
>> - depends on NETFILTER
>> + depends on NETFILTER && EXPERIMENTAL
>> ---help---
>> IP Virtual Server support will let you build a high-performance
>> virtual server based on cluster of two or more real servers. This
>
> there's maturity-level inconsistency like that in a few places, like
> when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE:
>
[ a lot examples ]
I know that and there are a lot more things depending on 'EXPERIMENTAL' and not having
EXPERIMENTAL visible all over the tree but that patch I've made for the _net_ part got
NACK'ed while your maturity idea and I rm -rf'ed all the other.
This one has a missing depends on EXPERIMENTAL while saying it is.
So *could* we please stop this maturity stuff for now ? I don't see it in .23 nor .24 if at all.
And even you get this kind changes for .24 almost a sed line will cleanup the whole tree from :
... "FOO blah (EXPERIMENTAL)" ...
so what is your problem ?
> rday
Gabriel
^ permalink raw reply
* [PATCH] defxx: Use __maybe_unused rather than a local hack
From: Maciej W. Rozycki @ 2007-07-20 12:14 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik; +Cc: netdev, linux-kernel
This is a change to remove a local hack in favour to __maybe_unused that
has been recently added.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Hi,
It should be obvious. The code builds, therefore it works.
Please apply,
Maciej
patch-mips-2.6.22-20070710-defxx-unused-0
diff -up --recursive --new-file linux-mips-2.6.22-20070710.macro/drivers/net/defxx.c linux-mips-2.6.22-20070710/drivers/net/defxx.c
--- linux-mips-2.6.22-20070710.macro/drivers/net/defxx.c 2007-07-10 04:56:16.000000000 +0000
+++ linux-mips-2.6.22-20070710/drivers/net/defxx.c 2007-07-20 00:05:14.000000000 +0000
@@ -200,6 +200,7 @@
/* Include files */
#include <linux/bitops.h>
+#include <linux/compiler.h>
#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/eisa.h>
@@ -240,8 +241,6 @@ static char version[] __devinitdata =
*/
#define NEW_SKB_SIZE (PI_RCV_DATA_K_SIZE_MAX+128)
-#define __unused __attribute__ ((unused))
-
#ifdef CONFIG_PCI
#define DFX_BUS_PCI(dev) (dev->bus == &pci_bus_type)
#else
@@ -375,7 +374,7 @@ static inline void dfx_outl(DFX_board_t
static void dfx_port_write_long(DFX_board_t *bp, int offset, u32 data)
{
- struct device __unused *bdev = bp->bus_dev;
+ struct device __maybe_unused *bdev = bp->bus_dev;
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
@@ -399,7 +398,7 @@ static inline void dfx_inl(DFX_board_t *
static void dfx_port_read_long(DFX_board_t *bp, int offset, u32 *data)
{
- struct device __unused *bdev = bp->bus_dev;
+ struct device __maybe_unused *bdev = bp->bus_dev;
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
@@ -866,7 +865,7 @@ static void __devinit dfx_bus_uninit(str
static void __devinit dfx_bus_config_check(DFX_board_t *bp)
{
- struct device __unused *bdev = bp->bus_dev;
+ struct device __maybe_unused *bdev = bp->bus_dev;
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int status; /* return code from adapter port control call */
u32 host_data; /* LW data returned from port control call */
@@ -3624,8 +3623,8 @@ static void __devexit dfx_unregister(str
}
-static int __devinit __unused dfx_dev_register(struct device *);
-static int __devexit __unused dfx_dev_unregister(struct device *);
+static int __devinit __maybe_unused dfx_dev_register(struct device *);
+static int __devexit __maybe_unused dfx_dev_unregister(struct device *);
#ifdef CONFIG_PCI
static int __devinit dfx_pci_register(struct pci_dev *,
@@ -3699,7 +3698,7 @@ static struct tc_driver dfx_tc_driver =
};
#endif /* CONFIG_TC */
-static int __devinit __unused dfx_dev_register(struct device *dev)
+static int __devinit __maybe_unused dfx_dev_register(struct device *dev)
{
int status;
@@ -3709,7 +3708,7 @@ static int __devinit __unused dfx_dev_re
return status;
}
-static int __devexit __unused dfx_dev_unregister(struct device *dev)
+static int __devexit __maybe_unused dfx_dev_unregister(struct device *dev)
{
put_device(dev);
dfx_unregister(dev);
^ permalink raw reply
* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Robert P. J. Day @ 2007-07-20 12:11 UTC (permalink / raw)
To: Gabriel C; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <46A0A01A.7030403@googlemail.com>
as a short followup to my previous post, at the *very least*, a
cleanup that could be done now is to find all entries which have an
actual dependency on "EXPERIMENTAL" but don't advertise themselves as
such:
...
config MA600_DONGLE
tristate "Mobile Action MA600 dongle"
depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
...
and determine which of those should have the dependency on
"EXPERIMENTAL" removed. no, don't go adding "(EXPERIMENTAL)" to the
prompt -- just deal with *only* those for which the dependency is
clearly out of date and not relevant anymore, and delete it.
that would be, at least, a place to start. and, yes, there's piles of
potential (net/ipv4/Kconfig):
config TCP_CONG_HSTCP
tristate "High Speed TCP"
depends on EXPERIMENTAL
...
config TCP_CONG_HYBLA
tristate "TCP-Hybla congestion control algorithm"
depends on EXPERIMENTAL
...
config TCP_CONG_VEGAS
tristate "TCP Vegas"
depends on EXPERIMENTAL
...
... etc etc ...
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Krishna Kumar2 @ 2007-07-20 12:09 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <46A09A85.7020500@trash.net>
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007:
> I can't really argue about the numbers, but it seems to me that only
> devices which *usually* have a sufficient queue length will support
> this, and anyone setting the queue length of a gbit device to <16 is
> begging for trouble anyway. So it doesn't really seem worth to bloat
> the code for handling an insane configuration as long as it doesn't
> break.
Ah, I get your point now. So if driver sets BATCHING and user then sets
queue_len to (say) 4, then poor results are expected (and kernel doesn't
need to try fix it). Same for driver setting BATCHING when it's queue is
small in the first place, which no driver writer should do anyway. I think
it makes the code a lot easier too. Will update.
thanks,
- KK
^ permalink raw reply
* Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Robert P. J. Day @ 2007-07-20 11:59 UTC (permalink / raw)
To: Gabriel C; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <46A0A01A.7030403@googlemail.com>
On Fri, 20 Jul 2007, Gabriel C wrote:
> Hi,
>
> IP_VS has :
>
> ..
>
> tristate "IP virtual server support (EXPERIMENTAL)"
>
> ..
>
> but it does not depend on EXPERIMENTAL.
>
>
> Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
>
> ---
>
> net/ipv4/ipvs/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig
> index 09d0c3f..3c594ec 100644
> --- a/net/ipv4/ipvs/Kconfig
> +++ b/net/ipv4/ipvs/Kconfig
> @@ -3,7 +3,7 @@
> #
> menuconfig IP_VS
> tristate "IP virtual server support (EXPERIMENTAL)"
> - depends on NETFILTER
> + depends on NETFILTER && EXPERIMENTAL
> ---help---
> IP Virtual Server support will let you build a high-performance
> virtual server based on cluster of two or more real servers. This
there's maturity-level inconsistency like that in a few places, like
when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE:
./net/ipv6/netfilter/Kconfig-config IP6_NF_QUEUE
./net/ipv6/netfilter/Kconfig- tristate "IP6 Userspace queueing via NETLINK (OBSOLETE)"
./net/ipv6/netfilter/Kconfig: depends on INET && IPV6 && NETFILTER && EXPERIMENTAL
and other examples:
./net/ipv6/netfilter/Kconfig-config IP6_NF_IPTABLES
./net/ipv6/netfilter/Kconfig- tristate "IP6 tables support (required for filtering)"
./net/ipv6/netfilter/Kconfig: depends on INET && IPV6 && EXPERIMENTAL
...
./net/ipv6/Kconfig-config IPV6_MULTIPLE_TABLES
./net/ipv6/Kconfig- bool "IPv6: Multiple Routing Tables"
./net/ipv6/Kconfig: depends on IPV6 && EXPERIMENTAL
...
./net/ipv4/Kconfig-config TCP_CONG_HSTCP
./net/ipv4/Kconfig- tristate "High Speed TCP"
./net/ipv4/Kconfig: depends on EXPERIMENTAL
...
./net/rxrpc/Kconfig-config AF_RXRPC
./net/rxrpc/Kconfig- tristate "RxRPC session sockets"
./net/rxrpc/Kconfig: depends on INET && EXPERIMENTAL
...
it might be a better investment in time to look through the Kconfig
files, and decide which entries currently marked as "EXPERIMENTAL"
really *shouldn't* be, and remove those silly dependencies.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Patrick McHardy @ 2007-07-20 11:55 UTC (permalink / raw)
To: Krishna Kumar2
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <OF316A971D.F3CBB5DC-ON6525731E.003F6683-6525731E.004131B7@in.ibm.com>
Krishna Kumar2 wrote:
> Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 04:50:37 PM
>> Is there any downside in using batching with smaller queue sizes?
>>
>
> I think there is, but as yet I don't have any data (and 16 is probably
> higher
> than reqd) to show it. If the queue size is very small (like 4), the extra
> processing to maintain this list may take more cycles than the performance
> gains for sending out few skbs, esp since most xmits will send out 1 skb
> and
> skb batching takes places less often (when tx lock fails or queue gets
> full).
>
> OTOH, there might be a gain to even send out 2 skbs, the problem is in
> doing
> the extra processing before xmit and not at the time of xmit.
>
> Does this sound OK ? If so, I will add the code to implement the TODO for
> tx_queue_len checking too.
>
I can't really argue about the numbers, but it seems to me that only
devices which *usually* have a sufficient queue length will support
this, and anyone setting the queue length of a gbit device to <16 is
begging for trouble anyway. So it doesn't really seem worth to bloat
the code for handling an insane configuration as long as it doesn't
break.
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Krishna Kumar2 @ 2007-07-20 11:52 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <46A09A85.7020500@trash.net>
Hi Patrick,
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 04:50:37 PM:
> > I have a TODO comment in net-sysfs.c which is to catch this case.
> >
>
> I noticed that. Still wondering why it is important at all though.
I saw another mail of yours on the marc list on this same topic (which
still hasn't come to me in the mail), so I will answer both :
> Is there any downside in using batching with smaller queue sizes?
I think there is, but as yet I don't have any data (and 16 is probably
higher
than reqd) to show it. If the queue size is very small (like 4), the extra
processing to maintain this list may take more cycles than the performance
gains for sending out few skbs, esp since most xmits will send out 1 skb
and
skb batching takes places less often (when tx lock fails or queue gets
full).
OTOH, there might be a gain to even send out 2 skbs, the problem is in
doing
the extra processing before xmit and not at the time of xmit.
Does this sound OK ? If so, I will add the code to implement the TODO for
tx_queue_len checking too.
> > Without going into GSO, it is wasting some 32 bytes on i386 since most
> > drivers don't export this API.
>
> 32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
> If you'd use it for gso_skb it would come down to 8 bytes. struct
> net_device is a pig already, and there are better ways to reduce this
> than starting to allocating single members with a few bytes IMO.
Sorry, I wanted to say 12 bytes on 32 bit system but mixed it up and
said 32 bytes. So I guess static allocation is better then, and it will
also help in performance as memory access is not required (offsetof
should work).
> Yes, packets can be holding references to various stuff and
> these should be released on device down. As I said above I
> don't really like the allocation, but even if you want to
> keep it, just do the purging and dev_deactivate and keep the
> freeing in unregister_netdev (actually I guess it should be
> free_netdev to handle register_netdevice errors).
Right, that makes it clean to do (and avoid stale packets on down).
I will make both these changes now.
Thanks for these suggestions,
- KK
^ permalink raw reply
* [PATCH] IP_VS should depend on EXPERIMENTAL ?
From: Gabriel C @ 2007-07-20 11:44 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev
Hi,
IP_VS has :
..
tristate "IP virtual server support (EXPERIMENTAL)"
..
but it does not depend on EXPERIMENTAL.
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
---
net/ipv4/ipvs/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig
index 09d0c3f..3c594ec 100644
--- a/net/ipv4/ipvs/Kconfig
+++ b/net/ipv4/ipvs/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig IP_VS
tristate "IP virtual server support (EXPERIMENTAL)"
- depends on NETFILTER
+ depends on NETFILTER && EXPERIMENTAL
---help---
IP Virtual Server support will let you build a high-performance
virtual server based on cluster of two or more real servers. This
^ permalink raw reply related
* [ofa-general] Re: [PATCH 05/10] sch_generic.c changes.
From: Patrick McHardy @ 2007-07-20 11:24 UTC (permalink / raw)
To: Krishna Kumar2
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <OF9D893096.26B48226-ON6525731E.003999A1-6525731E.0039ED23@in.ibm.com>
Krishna Kumar2 wrote:
> Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:41:01 PM:
>
>>> -static inline int qdisc_restart(struct net_device *dev)
>>> +static inline int qdisc_restart(struct net_device *dev,
>>> + struct sk_buff_head *blist)
>>> {
>>> struct Qdisc *q = dev->qdisc;
>>> struct sk_buff *skb;
>>> - unsigned lockless;
>>> + unsigned getlock; /* whether we need to get lock or not */
>>>
>> Unrelated rename, please get rid of this to reduce the noise.
>>
>
> OK, I guess I should have sent that change earlier :) The reason to change
> the name is to avoid (double-negative) checks like :
>
> if (!lockless)
> to
> if (getlock).
>
> I will remove these changes.
>
I guess you could put it in another patch. But frankly, I think
the biggest uglyness is the conditional locking, not naming or
double negation, so it won't really make the code any nicer :)
^ permalink raw reply
* [ofa-general] Re: [PATCH 04/10] net-sysfs.c changes.
From: Patrick McHardy @ 2007-07-20 11:21 UTC (permalink / raw)
To: Krishna Kumar2
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <OF3743242C.0BC81AC3-ON6525731E.00397CC1-6525731E.00399244@in.ibm.com>
Krishna Kumar2 wrote:
> Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:37:20 PM:
>
>
>
>> rtnetlink support seems more important than sysfs to me.
>>
>
> Thanks, I will add that as a patch. The reason to add to sysfs is that
> it is easier to change for a user (and similar to tx_queue_len).
>
Thanks.
^ permalink raw reply
* [ofa-general] Re: [PATCH 03/10] dev.c changes.
From: Patrick McHardy @ 2007-07-20 11:20 UTC (permalink / raw)
To: Krishna Kumar2
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <OFC586F180.42DDCDC5-ON6525731E.0038D792-6525731E.00397615@in.ibm.com>
Krishna Kumar2 wrote:
> Hi Patrick,
>
> Thanks for your comments.
>
> Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:34:30 PM:
>
>
>> The queue length can be changed through multiple interfaces, if that
>> really is important you need to catch these cases too.
>>
>
> I have a TODO comment in net-sysfs.c which is to catch this case.
>
I noticed that. Still wondering why it is important at all though.
>
>>> + } else {
>>> + dev->skb_blist = kmalloc(sizeof *dev->skb_blist,
>>> + GFP_KERNEL);
>>>
>> Why not simply put the head in struct net_device? It seems to me that
>> this could also be used for gso_skb.
>>
>
> Without going into GSO, it is wasting some 32 bytes on i386 since most
> drivers don't export this API.
>
32 bytes? I count 16, - 4 for the pointer, so its 12 bytes of waste.
If you'd use it for gso_skb it would come down to 8 bytes. struct
net_device is a pig already, and there are better ways to reduce this
than starting to allocating single members with a few bytes IMO.
>
>> Queue purging should be done in dev_deactivate.
>>
>
> I originally had it in dev_deactivate, but when I did a ifdown eth0, ifup
> eth0,
> the system panic'd. The first solution I thought was to initialize the
> skb_blist
> in dev_change_flags() rather than in register_netdev(), but then felt that
> a
> series of ifup/ifdown will unnecessarily check stuff/malloc/free/initialize
> stuff,
> and so thought of putting it in unregister_netdev (where it is balanced
> with
> register_netdev).
>
> Is there any reason to move this ?
>
Yes, packets can be holding references to various stuff and
these should be released on device down. As I said above I
don't really like the allocation, but even if you want to
keep it, just do the purging and dev_deactivate and keep the
freeing in unregister_netdev (actually I guess it should be
free_netdev to handle register_netdevice errors).
^ permalink raw reply
* Re: [PATCH 03/10] dev.c changes.
From: Krishna Kumar2 @ 2007-07-20 10:27 UTC (permalink / raw)
To: Patrick McHardy
Cc: davem, gaagaan, general, hadi, herbert, jagana, jeff, johnpol,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr, rdreier,
rick.jones2, Robert.Olsson, sri, tgraf, xma
In-Reply-To: <46A088AE.1090702@trash.net>
Hi Patrick,
Thanks for your comments.
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:34:30 PM:
> The queue length can be changed through multiple interfaces, if that
> really is important you need to catch these cases too.
I have a TODO comment in net-sysfs.c which is to catch this case.
> > + } else {
> > + dev->skb_blist = kmalloc(sizeof *dev->skb_blist,
> > + GFP_KERNEL);
>
>
> Why not simply put the head in struct net_device? It seems to me that
> this could also be used for gso_skb.
Without going into GSO, it is wasting some 32 bytes on i386 since most
drivers
don't export this API.
> Queue purging should be done in dev_deactivate.
I originally had it in dev_deactivate, but when I did a ifdown eth0, ifup
eth0,
the system panic'd. The first solution I thought was to initialize the
skb_blist
in dev_change_flags() rather than in register_netdev(), but then felt that
a
series of ifup/ifdown will unnecessarily check stuff/malloc/free/initialize
stuff,
and so thought of putting it in unregister_netdev (where it is balanced
with
register_netdev).
Is there any reason to move this ?
Thanks,
- KK
^ permalink raw reply
* Re: ANNOUNCE: igb: Intel 82575 Gigabit Ethernet driver (PCI-Express)
From: Jeff Garzik @ 2007-07-20 11:00 UTC (permalink / raw)
To: Kok, Auke
Cc: NetDev, Arjan van de Ven, Ronciak, John, Mitch Williams,
Andrew Morton, David Miller
In-Reply-To: <469FF922.2090900@intel.com>
Kok, Auke wrote:
> Jeff Garzik wrote:
>> Kok, Auke wrote:
>>> http://foo-projects.org/~sofar/igb.patch [558K]
>>> http://foo-projects.org/~sofar/igb.patch.bz2 [98K]
>>
>> Just took a look at this.
>>
>> This has the same problem as in the other thread -- huge internal API
>> -- except this time, the problem is emphasized by the fact that the
>> majority of the API hooks only have a single user, making each hook
>> and API entry point demonstrably useless overhead.
>>
>> Please remove the useless internal API and resubmit.
>
> Why don't you accept it now and allow us the time to work on this in the
> coming period? The driver works, performs better than all 8257x hardware
> and uses less CPU utilization. That must be good for everyone. Keeping
> it outside of the linux tree is just going to postpone testing the
> non-internal API parts.
I do not know how to say it more clearly than it has been said for weeks:
do-anything internal API is a merge stopper.
_Especially_ in igb's case, more than others, because it is obviously a
one-user-per-hook no-op API. Pure overhead. 100% real pork products.
Since you praise it in the following paragraphs, that demonstrates
previous little incentive to remove it, if I merge this driver as-is.
>> PLEASE take a look at how bnx2 and tg3 are structured.
>
> They don't use PHYlib. Nobody is perfect...
>
> We can and we should be able to _not_ agree on certain things and live
> together just fine. While I agree that some designs are better, the
> current internal API design has worked really good for us and allowed us
> to develop this driver and ixgbe in much faster rate than ever before.
> It was most useful in silicon validation and extremely flexible for us.
> At one point, the 82575 silicon was even supporter by the e1000 driver,
> because this internal API made it so easy to add new hardware support.
> For obvious reasons (differences in hw) we decided to split this driver
> off.
This is the same argument we get from every vendor who wants to keep
their lovely cross-OS modularization/etc. API.
igb has been submitted in OBVIOUSLY BLOATED state. I could care less
how useful it was in silicon validation, if this is the result: an
implement-any-MAC-or-PHY-in-the-world internal API where every hook...
has precisely ONE user, thus obviating the need for the hook and API at
all. Simple mathematical reduction.
> It served a good purpose. We can improve it, and I sure want to do that,
> but I think it's better to improve something *upstream*, then going back
> working at things offline without having any certainty that you will
> accept it after I get back, since you might just reject it on another
> argument, etc. It will take quite some effort and convincing to make
> this happen, and it would help a lot if we can work with/in the
> community on that, instead of off-line.
Let us review the e1000new major merge objections (posted July 9, msgid
<469280F5.8000909@garzik.org>):
1) Transition plan (irrelevant to this igb thread)
2) Internal do-anything API
3) Lack of Intel attention to on-going driver maintenance and
cleanups, rather than strict focus bolting on new features
or fixes.
Intel is just wasting everybody's time by coming back with a new driver
that will spark the same objection (#2) as with the previous driver.
You then ask the Linux community to TRUST you that you will clean up a
driver, running counter to experience associated with objection #3.
It needs to look like a lean and mean Linux driver, not a driver with
CLEAR bloat left over from silicon validation. Your customers -- my
users -- deserve much better.
Here is the key: I don't expect perfection (much to Christoph's chagrin
:)) in a driver submission. I want to see three key things in a new driver:
1) it's clean
2) it is a good foundation for the future
3) stable, reliable, active maintainership process exists
Arjan says #3 is in place, so we will take that on faith. It's mostly
clean (#1), but it's mainly problem is that it's overengineered. This
igb driver violates one of Linux's key principles: "do what you must,
and no more." That internal API, demonstrably a no-op in igb, is not a
good foundation for the future (#2).
With regards to "certainty"... you should know that there are never any
promises. I have to look at each incarnation with fresh eyes. ASSUMING
the driver is moving in the right direction (i.e. author accepts
feedback), each re-review should be more rapid. But it is key to
understand that often initial comments and initial revisions are
required simply to make the driver reviewable. This is the natural
process that every driver goes through.
But if you want certainty, I would be more than happy to take igb as-is,
merge it into netdev-2.6.git, clean it up myself to illustrate the
proper direction, and then push it upstream. That would get a modified
igb upstream sooner rather than later. Would that be preferred? I
could knock that out this weekend. Or I am happy to mentor. Whatever
it takes.
Whoever does it, this needs a lot of simple algabraic/logical reductions.
It needs to look like, to be, a Linux driver first and foremost. Linux
users should not suffer needless bloat because of the happenstance of
the internal silicon validation process.
Jeff
^ permalink raw reply
* Re: Socket Buffers and Memory Managment
From: Andi Kleen @ 2007-07-20 11:50 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: vinay ravuri, Stephen Hemminger, netdev
In-Reply-To: <20070719090826.GA14860@2ka.mipt.ru>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
> Hi.
>
> On Wed, Jul 18, 2007 at 11:51:03PM -0700, vinay ravuri (vinaynyc@yahoo.com) wrote:
> > How about the following approach:
> >
> > I allocate an skb of 0 bytes and replace data element
> > of skb struct (i.e. skb.data = addr_given_by_hw) when
> > the h/w interrupts me with a packet. I register for a
> > destructor for this skb and when the kernel is ready
> > to free the skb, I make sure that my free is invoked -
> > Ofcourse this is assuming that their is a facility in
> > linux socket buffers to be able to do destructors. Is
> > this approach a viable, if so, are any gottcha's?
>
> It will not work, since kfree_skb() eventually tries to free skb->head
> into kmem cache,
And in addition if the skbuff is ever passed towards the socket
layer the destructor will be overwritten
-Andi
^ permalink raw reply
* [ofa-general] Re: [PATCH 05/10] sch_generic.c changes.
From: Krishna Kumar2 @ 2007-07-20 10:32 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <46A08A35.5090104@trash.net>
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:41:01 PM:
> Krishna Kumar wrote:
> > diff -ruNp org/net/sched/sch_generic.c new/net/sched/sch_generic.c
> > --- org/net/sched/sch_generic.c 2007-07-20 07:49:28.000000000 +0530
> > +++ new/net/sched/sch_generic.c 2007-07-20 08:30:22.000000000 +0530
> > @@ -9,6 +9,11 @@
> > * Authors: Alexey Kuznetsov, <kuznet@ms2.inr.ac.ru>
> > * Jamal Hadi Salim, <hadi@cyberus.ca> 990601
> > * - Ingress support
> > + *
> > + * New functionality:
> > + * Krishna Kumar, <krkumar2@in.ibm.com>, July 2007
> > + * - Support for sending multiple skbs to devices that support
> > + * new api - dev->hard_start_xmit_batch()
>
>
> No new changelogs in source code please, git keeps track of that.
Ah, didn't know this, thanks for letting me know.
> > -static inline int qdisc_restart(struct net_device *dev)
> > +static inline int qdisc_restart(struct net_device *dev,
> > + struct sk_buff_head *blist)
> > {
> > struct Qdisc *q = dev->qdisc;
> > struct sk_buff *skb;
> > - unsigned lockless;
> > + unsigned getlock; /* whether we need to get lock or not */
>
>
> Unrelated rename, please get rid of this to reduce the noise.
OK, I guess I should have sent that change earlier :) The reason to change
the name is to avoid (double-negative) checks like :
if (!lockless)
to
if (getlock).
I will remove these changes.
thanks,
- KK
^ permalink raw reply
* [ofa-general] Re: [PATCH 04/10] net-sysfs.c changes.
From: Krishna Kumar2 @ 2007-07-20 10:28 UTC (permalink / raw)
To: Patrick McHardy
Cc: jagana, johnpol, herbert, gaagaan, Robert.Olsson, kumarkr,
rdreier, peter.p.waskiewicz.jr, hadi, mcarlson, jeff, general,
mchan, tgraf, netdev, davem, sri
In-Reply-To: <46A08958.3090509@trash.net>
Patrick McHardy <kaber@trash.net> wrote on 07/20/2007 03:37:20 PM:
> Krishna Kumar wrote:
> > Support to turn on/off batching from /sys.
>
>
> rtnetlink support seems more important than sysfs to me.
Thanks, I will add that as a patch. The reason to add to sysfs is that
it is easier to change for a user (and similar to tx_queue_len).
- KK
^ permalink raw reply
* [ofa-general] Re: [PATCH 05/10] sch_generic.c changes.
From: Patrick McHardy @ 2007-07-20 10:11 UTC (permalink / raw)
To: Krishna Kumar
Cc: johnpol, Robert.Olsson, peter.p.waskiewicz.jr, herbert, gaagaan,
kumarkr, rdreier, mcarlson, netdev, jagana, general, mchan, tgraf,
jeff, hadi, davem, sri
In-Reply-To: <20070720063249.26341.125.sendpatchset@localhost.localdomain>
Krishna Kumar wrote:
> diff -ruNp org/net/sched/sch_generic.c new/net/sched/sch_generic.c
> --- org/net/sched/sch_generic.c 2007-07-20 07:49:28.000000000 +0530
> +++ new/net/sched/sch_generic.c 2007-07-20 08:30:22.000000000 +0530
> @@ -9,6 +9,11 @@
> * Authors: Alexey Kuznetsov, <kuznet@ms2.inr.ac.ru>
> * Jamal Hadi Salim, <hadi@cyberus.ca> 990601
> * - Ingress support
> + *
> + * New functionality:
> + * Krishna Kumar, <krkumar2@in.ibm.com>, July 2007
> + * - Support for sending multiple skbs to devices that support
> + * new api - dev->hard_start_xmit_batch()
No new changelogs in source code please, git keeps track of that.
> -static inline int qdisc_restart(struct net_device *dev)
> +static inline int qdisc_restart(struct net_device *dev,
> + struct sk_buff_head *blist)
> {
> struct Qdisc *q = dev->qdisc;
> struct sk_buff *skb;
> - unsigned lockless;
> + unsigned getlock; /* whether we need to get lock or not */
Unrelated rename, please get rid of this to reduce the noise.
^ 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