Hi,
Read below, please:
On Thu, May 10, 2007 at 12:06:09AM +0400, Yuriy N. Shkandybin wrote:
> After applying this patch i've got this:
>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-gentoo #2
> -
Hi,
I encountered the following error when I was hot-plugging network card
using pci hotplug driver.
kobject_add failed for eth8 with -EEXIST, don't try to register things with the
same name in the same directory.
Call Trace:
[] show_stack+0x40/0xa0
sp=e0006
Krishna Kumar2 wrote:
What about a race between trying to reacquire queue_lock and another
failed transmit?
That is not possible too. I hold the QDISC_RUNNING bit in dev->state and
am the only sender for this device, so there is no other failed transmit.
Also, on failure of dev_hard_start_xmit,
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Why do you call SetPageUptodate when the page is not up to date?
That leaks uninitialised data, AFAIKS.
It only seems that way. If afs_prepare_write() is called, but doesn't return
an error, then afs_commit_write() will be called,
Hi Gagan,
Gagan Arneja <[EMAIL PROTECTED]> wrote on 05/11/2007 11:27:54 AM:
> >
> > Right, but I am the sole dequeue'r, and on failure, I requeue those
packets
> > to
> > the beginning of the queue (just as it would happen in the regular case
of
> > one
> > packet xmit/failure/requeue).
>
> What
From: Jan Engelhardt <[EMAIL PROTECTED]>
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Dominik Brodowski
From: Jan Engelhardt <[EMAIL PROTECTED]>
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Krzysztof Halasa <
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/net/netxen/netxen_nic_main.c: In function 'netxen_nic_open':
drivers/net/netxen/netxen_nic_main.c:738: warning: 'deprecated_irq_flag' is
deprecated (declared at include/linux/interrupt.h:66)
drivers/net/netxen/netxen_nic_main.c:738: warning: 'deprec
From: Andrew Morton <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/mlx4/eq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/mlx4/eq.c~mlx4-dont-use-deprecated-irq-flags
drivers/net/mlx4/eq
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 05/11/2007 02:27:07 AM:
> > I don't understand how transmitting already batched up packets in one
go
> > introduce latency.
>
> Keep thinking :-)
>
> The only case where these ideas can be seriously considered is during
> netif_wake_queue(). In
Andrew,
On 5/11/07, Andrew Hall <[EMAIL PROTECTED]> wrote:
> > When accessing certain web sites when using any kernel above 2.6.19,
> TCP seems to break. Connection to the site is established but never
> completes.
Is it happening with a single connection, or when trying tens, hundreds,
thousa
Right, but I am the sole dequeue'r, and on failure, I requeue those packets
to
the beginning of the queue (just as it would happen in the regular case of
one
packet xmit/failure/requeue).
What about a race between trying to reacquire queue_lock and another
failed transmit?
--
Gagan
- KK
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTEC
From: Matthias Kaehlcke <[EMAIL PROTECTED]>
Use mutex instead of binary semaphore in idt77252 driver.
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Cc: chas williams <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/atm/idt77252.c | 27 ++-
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Per Liden <[EMAIL PROTECTED]>
Cc: Jon Maloy <[EMAIL PROTECTED]>
Cc: Allan Stephens <[EMA
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Acked-by: Simon Horman <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/tokenring/Kconfig | 33
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/arcnet/Kconfig | 17 +++
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Vlad Yasevich <[EMAIL PROTECTED]>
Cc: Sridhar Samudrala <[EMAIL PROTECTED]>
Signed-off-b
From: Milan Kocian <[EMAIL PROTECTED]>
When you replace route via ip r r command the netlink multicast message is
not send. This patch corrects it. NL message is sent with NLM_F_REPLACE
flag. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=8320
Signed-off-by: Milan Kocian <[EMAIL PROTECTE
From: Jarek Poplawski <[EMAIL PROTECTED]>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-rc4 #1
> ---
> pppd/8926 is trying to acquire lock:
> (&vlan_netdev_xmit_lock_k
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
d
From: "Wu, Bryan" <[EMAIL PROTECTED]>
This patch implements the driver necessary use the Analog Devices
Blackfin processor's on-chip ethernet MAC controller.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
driv
From: Jan Engelhardt <[EMAIL PROTECTED]>
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[
From: Jan Engelhardt <[EMAIL PROTECTED]>
CONFIG_NETDEVICES, CONFIG_NET_ETHERNET:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.
CONFIG_SMC9194:
Move it so that it appears correctly in menuconfig.
From: Bernard Lee <[EMAIL PROTECTED]>
Setting bit 4 & 5 alone in 8139too module media option does not really
force 100Mbps full-duplex mode. When media option bit 0-3 is cleared,
8139too module does not force media setting. Therefore, bit 0-3 requires
to be set for bit 4 & 5 to take effect. The
From: Ingo Molnar <[EMAIL PROTECTED]>
Another forcedeth.c thing: i noticed that its NAPI handler does not do
tx-ring processing. The patch below implements this - tested on DESC_VER_2
hardware, with CONFIG_FORCEDETH_NAPI=y.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Ayaz Abdulla <[EMAIL
From: Jan Engelhardt <[EMAIL PROTECTED]>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
d
On May 10, 2007, at 00:34:11, Kyle Moffett wrote:
On May 10, 2007, at 00:25:54, Ben Greear wrote:
Looks like a deadlock in the vlan code. Any chance you can run
this test with lockdep enabled?
You could also add a printk in vlan_device_event() to check which
event it is hanging on, and the
Gagan Arneja <[EMAIL PROTECTED]> wrote on 05/11/2007 11:05:47 AM:
> Krishna Kumar2 wrote:
> > I haven't seen reordering packets (I did once when I was having a bug
in
> > the requeue code, some TCP messages on receiver indicating packets out
of
> > order). When a send fails, the packet are requeue
Krishna Kumar2 wrote:
I haven't seen reordering packets (I did once when I was having a bug in
the requeue code, some TCP messages on receiver indicating packets out of
order). When a send fails, the packet are requeued in reverse (go to end of
the failed skb and traverse back to the failed skb a
J Hadi Salim <[EMAIL PROTECTED]> wrote on 05/11/2007 01:41:27 AM:
> > It's not just small packets. The cost of calling hard_start_xmit/byte
> > was rather high on your particular device. I've seen PCI read
> > transaction in hard_start_xmit taking ~10,000 cycles on one particular
> > device. Coun
David Miller <[EMAIL PROTECTED]> wrote on 05/11/2007 02:07:10 AM:
> From: Gagan Arneja <[EMAIL PROTECTED]>
> Date: Thu, 10 May 2007 12:43:53 -0700
> >
> > Also, I think, you don't have to chain skbs, they're already chained in
> > Qdisc->q. All you have to do is take the whole q and try to shov
Gagan Arneja <[EMAIL PROTECTED]> wrote on 05/11/2007 01:13:53 AM:
> Also, I think, you don't have to chain skbs, they're already chained in
> Qdisc->q. All you have to do is take the whole q and try to shove it
> at the device hoping for better results. But then, if you have rather
> big backlog
> -Original Message-
> From: Robert Iakobashvili [mailto:[EMAIL PROTECTED]
> Sent: Friday, 11 May 2007 2:38 PM
> To: Andrew Hall
> Cc: netdev@vger.kernel.org
> Subject: Re: Accessing certain web sites broken from 2.6.19+
>
> On 5/11/07, Andrew Hall <[EMAIL PROTECTED]> wrote:
> > When acces
> If you have braindead slow hardware,
> there is nothing that says your start_xmit routine can't do its own
> coalescing. The cost of calling the transmit routine is the
responsibility
> of the driver, not the core network code.
Yes, except you very likely run the risk of the driver introduci
"Ian McDonald" <[EMAIL PROTECTED]> wrote on 05/11/2007 12:29:08 AM:
>
> As I see this proposed patch it is about reducing the number of "task
> switches" between the driver and the protocol. I use task switch in
> speech marks as it isn't really as is in the kernel. So in other words
> we are hopi
On 5/11/07, Andrew Hall <[EMAIL PROTECTED]> wrote:
When accessing certain web sites when using any kernel above 2.6.19, TCP
seems to break. Connection to the site is established but never completes.
One particular site is www.dcita.gov.au. Is there a known issue pertaining
to this? Using any kern
When accessing certain web sites when using any kernel above 2.6.19, TCP
seems to break. Connection to the site is established but never completes.
One particular site is www.dcita.gov.au. Is there a known issue pertaining
to this? Using any kernel below 2.6.19 (for example: 2.6.12 or 2.6.15) works
Hi,
> >>I don't see why this is needed, the correct way to use TBF with TSO
> >>is to specify a larger MTU value, in which case it won't drop TSO
> >>packets.
> >
> >
> > Why should a user have to know anything in the world about TSO in
> > order to configure TBF properly? I don't think they sh
Tomohiro Kusumi wrote:
Dear Auke
> I'm ok with the bottom part of the patch, but I do not like
> the modification of the pci device ID table in this way. As
> Arjan van der Ven previously commented as well, this makes
> it hard for future device ID's to be bound to the driver.
I googled t
On Fri, May 11, 2007 at 11:27:22AM +0900, Simon Horman wrote:
> On Thu, May 10, 2007 at 09:13:34PM -0500, Kumar Gala wrote:
> > On Fri, 11 May 2007, Simon Horman wrote:
> >
> > > On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > > > Try this patch:
> > >
> > > That certainly resolves
Dear Auke
> I'm ok with the bottom part of the patch, but I do not like
> the modification of the pci device ID table in this way. As
> Arjan van der Ven previously commented as well, this makes
> it hard for future device ID's to be bound to the driver.
I googled the previous comment by Arjan.
Simon Horman wrote:
I agree. I had thought a little about a kconfig fix. Though I'm
wondering if removing the warning will lead to oodles of dangling
symbols and invalid checks over time.
I'm pretty sure it will. Perhaps we need to have a lint for Kconfig?
-
To unsubscribe from this list: se
On Thu, 10 May 2007 14:14:05 -0700
Gagan Arneja <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
> > From: Rick Jones <[EMAIL PROTECTED]>
> > Date: Thu, 10 May 2007 13:49:44 -0700
> >
> >> I'd think one would only do this in those situations/places where a
> >> natural "out of driver" queue devel
On Thu, May 10, 2007 at 09:13:34PM -0500, Kumar Gala wrote:
> On Fri, 11 May 2007, Simon Horman wrote:
>
> > On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > > Try this patch:
> >
> > That certainly resolves the problem for me.
> > I'll see about doing something like that for the si
On Fri, 2007-11-05 at 09:58 +0800, Zhu Yi wrote:
>
> Good, we agree on this.
Good start.
> Now let's solve the problem.
>
Lets take it slowly, because i think i wasnt getting anywhere with
Peter. See if you make sense of what i am saying maybe we can make
progress.
> When the low priority r
On Fri, 11 May 2007, Simon Horman wrote:
> On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > Try this patch:
>
> That certainly resolves the problem for me.
> I'll see about doing something like that for the similar
> Kconfig problems that I see.
>
> --
> Horms
> H: http://www.verg
The UCC_GETH Kconfig option in drivers/net/Kconfig had a line to select
the UCC_FAST option is arch/powerpc/sysdev/qe_lib/Kconfig, which is only used
on PowerPC builds. On other architectures, this would generated a warning.
The fix is to have UCC_FAST depend on UCC_GETH.
Signed-off-by: Timur Tab
On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> Try this patch:
That certainly resolves the problem for me.
I'll see about doing something like that for the similar
Kconfig problems that I see.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To un
On Thu, 2007-05-10 at 08:35 -0400, jamal wrote:
> So we may be agreeing then?
> In other words, if you had both low prio and high prio in WMM
> scheduler
> (in wireless hardware) then the station favors a higher priority
> packet
> over at low priority packet at ALL times.
> IOW:
> Given the defaul
Sorry about previous html/non-inline version which escaped.
This patch provides a performance optimization in the pfkey_add path.
Prior versions have a serious performance problem when adding a large
number of SAs to a node. For example, if a backup node needs to be
loaded with the SAs previousl
On May 10, 2007, at 8:25 PM, Simon Horman wrote:
On Thu, May 10, 2007 at 11:56:48AM -0500, Timur Tabi wrote:
Simon Horman wrote:
So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and
"UCC_SLOW_TEMP"? At first I thought, just put it in drivers/
Kconfig, but
that Kconfig does n
On Fri, 11 May 2007, Simon Horman wrote:
> On Thu, May 10, 2007 at 11:56:48AM -0500, Timur Tabi wrote:
> > Simon Horman wrote:
> >
> > >>So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and
> > >>"UCC_SLOW_TEMP"? At first I thought, just put it in drivers/Kconfig, but
> > >>that Kc
On Thu, May 10, 2007 at 11:56:48AM -0500, Timur Tabi wrote:
> Simon Horman wrote:
>
> >>So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and
> >>"UCC_SLOW_TEMP"? At first I thought, just put it in drivers/Kconfig, but
> >>that Kconfig does nothing but including other Kconfigs. I
On Thu, May 10, 2007 at 05:39:29PM +0200, Johannes Berg wrote:
> On Thu, 2007-05-10 at 14:10 +0900, Simon Horman wrote:
>
> > drivers/macintosh/Kconfig:112:warning: 'select' used by config symbol
> > 'PMAC_APM_EMU' refer to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
>
> Argh. Is that with ARC
On Thu, 10 May 2007 14:04:13 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.21-gitX.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
>
>
> Unclassified:
>
> Subject: 2.
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Thu, 10 May 2007 14:56:39 +0200
>
>>I don't see why this is needed, the correct way to use TBF with TSO
>>is to specify a larger MTU value, in which case it won't drop TSO
>>packets.
>
>
> Why should a user have to know anyt
This patch provides a performance optimization in the pfkey_add path.
Prior versions have a serious performance problem when adding a large
number of SAs to a node. For example, if a backup node needs to be
loaded with the SAs previously held by a failed active node, thousands
of SAs may need to
This compiles and passes some basic tests - no serious testing.
Against net-2.6.
The patch is ugly looking, so i have at the end the re-written qdisc;
you can easily tell the rest from the patch.
Please flush out any fluff - I would like to submit this (almost lost
it, thanks to an early posting
On Thu, 10 May 2007 15:33:34 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> Following bug was uncovered by compiling with '-W' flag:
gcc -W finds a number of fairly scary bugs.
More than one would expect, given that it is recommended in
Documentation/SubmitChecklist, which everyone reads ;)
-
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Yep, this patch gets rid of my spinning thread. I can't find this patch
> or any discussion on marc.info; is there a better netdev list archive?
See the "linkwatch bustage in git-net" thread on netdev
http://thread.gmane.org/gmane.linux.network/
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 15:45:42 -0700
> David Miller wrote:
> > I'm not so certain now that we know it's the jiffies wrap point :-)
> >
> > The fixes in question are attached below and they were posted and
> > discussed on netdev:
> >
>
> Yep, this
> -Messaggio originale-
> Da: Chuck Ebbert [mailto:[EMAIL PROTECTED]
>
> Giampaolo Tomassoni wrote:
> >
> > default src 1.2.1.6
> > nexthop via 1.2.2.254 dev atm0 weight 1
> > nexthop via 1.1.2.254 dev atm1 weight 1
> >
>
> When I tri
David Miller wrote:
> I'm not so certain now that we know it's the jiffies wrap point :-)
>
> The fixes in question are attached below and they were posted and
> discussed on netdev:
>
Yep, this patch gets rid of my spinning thread. I can't find this patch
or any discussion on marc.info; is th
Giampaolo Tomassoni wrote:
>
> default src 1.2.1.6
> nexthop via 1.2.2.254 dev atm0 weight 1
> nexthop via 1.1.2.254 dev atm1 weight 1
>
When I tried this I found that weight 1 didn't work -- all traffic
went out one interface until I
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 15:22:17 -0700
> Andrew Morton wrote:
> > Five minutes after boot is when jiffies wraps. Are you sure it's
> > a list-screwup rather than a jiffy-wrap screwup?
> >
>
>
> Hm, its suggestive, isn't it? Apparently they've alr
Andrew Morton wrote:
> Five minutes after boot is when jiffies wraps. Are you sure it's
> a list-screwup rather than a jiffy-wrap screwup?
>
Hm, its suggestive, isn't it? Apparently they've already fixed this in
the sekret networking clubhouse, so I'll need to track it down.
J
-
To unsu
On Thu, 10 May 2007 15:00:05 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Herbert Xu wrote:
> > [NET] link_watch: Move link watch list into net_device
> >
> > These days the link watch mechanism is an integral part of the
> > network subsystem as it manages the carrier status. So it now
David Miller wrote:
> From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Date: Thu, 10 May 2007 15:00:05 -0700
>
>
>> Herbert Xu wrote:
>>
>>> [NET] link_watch: Move link watch list into net_device
>>>
>>> These days the link watch mechanism is an integral part of the
>>> network subsystem as
Eric Dumazet wrote:
David Stevens a écrit :
The word "small" is coming up a lot in this discussion, and
I think packet size really has nothing to do with it. Multiple
streams generating packets of any size would benefit; the
key ingredient is a queue length greater than 1.
I think the intent i
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 15:00:05 -0700
> Herbert Xu wrote:
> > [NET] link_watch: Move link watch list into net_device
> >
> > These days the link watch mechanism is an integral part of the
> > network subsystem as it manages the carrier status. So it n
From: Gagan Arneja <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 14:50:19 -0700
> David Miller wrote:
>
> > If you drop the TX lock, the number of free slots can change
> > as another cpu gets in there queuing packets.
>
> Can you ever have more than one thread inside the driver? Isn't
> xmit_lock
Herbert Xu wrote:
> [NET] link_watch: Move link watch list into net_device
>
> These days the link watch mechanism is an integral part of the
> network subsystem as it manages the carrier status. So it now
> makes sense to allocate some memory for it in net_device rather
> than allocating it on de
> Which worked _very_ well (the whole list) going in the other direction
for the
> netisr queue(s) in HP-UX 10.20. OK, I promise no more old HP-UX stories
for the
> balance of the week :)
Yes, OSes I worked on in other lives usually took the whole queue
and then took responsibility fo
David Miller wrote:
Right.
But I think it's critical to do two things:
1) Do this when netif_wake_queue() is triggers and thus the
TX is locked already.
2) Have some way for the driver to say how many free TX slots
there are in order to minimize if not eliminate requeueing
during thi
David Stevens wrote:
The word "small" is coming up a lot in this discussion, and
I think packet size really has nothing to do with it. Multiple
streams generating packets of any size would benefit; the
key ingredient is a queue length greater than 1.
I think the intent is to remove queue lock cy
David Stevens a écrit :
The word "small" is coming up a lot in this discussion, and
I think packet size really has nothing to do with it. Multiple
streams generating packets of any size would benefit; the
key ingredient is a queue length greater than 1.
I think the intent is to remove queue lock
From: David Stevens <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 14:27:56 -0700
> The word "small" is coming up a lot in this discussion, and
> I think packet size really has nothing to do with it. Multiple
> streams generating packets of any size would benefit; the
> key ingredient is a queue lengt
The word "small" is coming up a lot in this discussion, and
I think packet size really has nothing to do with it. Multiple
streams generating packets of any size would benefit; the
key ingredient is a queue length greater than 1.
I think the intent is to remove queue lock cycles by taking
the whol
Hi there,
this is yet-another-question about multipath routing.
I would like to do load-balancing on traffic outgoing through two DSL lines.
I would prefer to increase the bandwidth of each connection instead of just
the total one, thereby I guess I'm looking for a packet-based multipath
routing
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 17:07:46 -0400
> Here in sys_recvmsg() line 1911:
>
> ==> if (sock->file->f_flags & O_NONBLOCK)
> flags |= MSG_DONTWAIT;
> err = sock_recvmsg(sock, &msg_sys, total_len, flags);
>
> sock == -1, apparently be
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 13:49:44 -0700
I'd think one would only do this in those situations/places where a
natural "out of driver" queue develops in the first place wouldn't
one?
Indeed.
And one builds in qdisc because your device sink
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 14:56:39 +0200
> Hirokazu Takahashi wrote:
> > TBF --- Simple Token Bucket Filter --- packet scheduler doesn't
> > work correctly with TSO on that it slows down to send out packets.
> > TSO packets will be discarded since the size ca
Oops. I thought Bill was using 2.6.20 instead of 2.6.22 which should contain
our latest update.
Regarding slow start behavior, the latest version should not change though.
I think it would be ok to change the slow start of bic and cubic to the
default slow start. But what we observed is that w
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 22:53:04 +1000
> [NET_SCHED]: Avoid requeue warning on dev_deactivate
>
> When we relinquish queue_lock in qdisc_restart and then retake it for
> requeueing, we might race against dev_deactivate and end up requeueing
> onto noop_qdisc.
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 22:10:10 +1000
> On Thu, May 10, 2007 at 04:55:34AM -0700, David Miller wrote:
> >
> > > [NET_SCHED]: Rationalise return value of qdisc_restart
> >
> > Fair enough, patch applied :-)
>
> Sorry, reading Thomas's patch made me realise tha
Croulder Croulder wrote:
> The next report is a Kernel NULL pointer dereference in tcp/ip (IPv4).
>
> I see that message all time in syslog.conf and console.
>
> Kernel compiled with gcc 4.1.1-> (Debian 4.1.1-21)
> Kernel Version: 2.6.21.1 (official source code)
> Processor: 2 x Xeon 2.8
>
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 13:49:44 -0700
> I'd think one would only do this in those situations/places where a
> natural "out of driver" queue develops in the first place wouldn't
> one?
Indeed.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
From: Gagan Arneja <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 13:40:22 -0700
> David Miller wrote:
> >
> > If the qdisc is packed with packets and we would just loop sending
> > them to the device, yes it might make sense.
> >
> > But if that isn't the case, which frankly is the usual case, you
David Miller wrote:
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 15:21:30 -0400
The win might be biggest on a system were a lot of applications send
a lot of small packets. Some number will aggregate in the prio
queue and then get shoved into a driver in one go.
But... thi
On Thu, 10 May 2007 13:35:22 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED]
> Date: Thu, 10 May 2007 14:39:25 -0400 (EDT)
>
> >
> > Bill,
> > Could you test with the lastest version of CUBIC? this is not the latest
> > version of it you tested.
>
> Rhee-sangsang-n
David Miller wrote:
If the qdisc is packed with packets and we would just loop sending
them to the device, yes it might make sense.
But if that isn't the case, which frankly is the usual case, you add a
non-trivial amount of latency by batching and that's bad exactly for
the kind of application
From: Kapil Juneja <[EMAIL PROTECTED]>
If connected via SGMII, initialize with SGMII mode configured.
Signed-off-by: Kapil Juneja <[EMAIL PROTECTED]>
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
somehow, a brace went missing from the prior ve
From: Gagan Arneja <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 12:43:53 -0700
> It's not just small packets. The cost of calling hard_start_xmit/byte
> was rather high on your particular device. I've seen PCI read
> transaction in hard_start_xmit taking ~10,000 cycles on one particular
> device
From: [EMAIL PROTECTED]
Date: Thu, 10 May 2007 14:39:25 -0400 (EDT)
>
> Bill,
> Could you test with the lastest version of CUBIC? this is not the latest
> version of it you tested.
Rhee-sangsang-nim, it might be a lot easier for people if you provide
a patch against the current tree for users to
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Thu, 10 May 2007 15:21:30 -0400
> The win might be biggest on a system were a lot of applications send
> a lot of small packets. Some number will aggregate in the prio
> queue and then get shoved into a driver in one go.
>
> But... this is all conjec
On Thu, 2007-10-05 at 21:21 +0200, Florian Fainelli wrote:
> Netdev people can probably comment on the place of
> ledtrig_network_activity(),
> which is probably not adequate. Also the ledtrig_network_activity can be
> network device specific for instance.
Thanks for CCing me Florian.
Yes, le
For example:
my biggest challenge with the e1000 was just hacking up the DMA setup
path - i seem to get better numbers if i dont kick the DMA until i stash
all the packets on the ring first etc. It seemed counter-intuitive.
That seems to make sense. The rings are(?) in system memory and you ca
This is pretty interesting to me for IP-over-InfiniBand, for a couple
of reasons. First of all, I can push multiple send requests to the
underlying adapter in one go, which saves taking and dropping the same
lock and also probably allows fewer MMIO writes for doorbells.
However the second reason
1 - 100 of 189 matches
Mail list logo
