My somewhat confusing netperf script (to run on client) is attached below.
Server just requires
to run netserver. Client is not completely accurate since I am not using
netperf4 (moving to
that after some initial hiccups).
thanks,
- KK
(See attached file: netperf.scp)
J Hadi Salim [EMAIL
Tim Mann wrote:
Hi, Michael. We have some IBM blades with a BCM5708-based dual-port
NIC that the bnx2 driver reports as not supporting wake-on-LAN.
(Ethtool says Supports Wake-on: d.) However, IBM says that WoL is
supported by these NICs, and in fact when I tried putting the blade
into
Patrick McHardy wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used
Alexey Kuznetsov [EMAIL PROTECTED] writes:
Hello!
Good point, I didn't think of that. Is there a version of this patch
that already uses different namespaces so I can look at it?
Pavel does not like the idea. It looks not exactly pretty, like you said.
:-)
The alternative is to create
On Wed, Jun 06, 2007 at 09:17:25AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
Some pages have zero reference counter here.
But it's somewhat annoying to get pages with zero reference counts
there, I wonder how that happens. I guess if the skb-data originated
from kmalloc() then we don't
David Miller wrote:
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
I would suggest
Michael Ellerman [EMAIL PROTECTED] wrote on 06/07/2007 02:35:00 AM:
On Wed, 2007-06-06 at 20:53 +0200, Thomas Klein wrote:
This patch fixes a possible kernel panic due to not checking the vlan
group
when processing received VLAN packets and a malfunction in
VLAN/hypervisor
registration.
On Wednesday 06 June 2007 23:04:07 Stephen Hemminger wrote:
I don't think we need +1, if you need to fire immediately
(on the next tick). The timer core will always fire
timers that are in the past immediately.
Thanks, but is it worth bothering to change it again?
No, I don't think so.
Hi Jamal,
I ran these bits today and the results are included. For comparison, I am
running 2.6.22-rc3 original bits. The systems are both 2.8Ghz, 2 cpu, P4,
2GB RAM, one E1000 82547GI card connected using a crossover cable.
The test runs for 3 mins for each case. I have run only once instead of
From: Kirill Korotaev [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 12:14:29 +0400
David Miller wrote:
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a
Pavel Emelianov wrote:
Patrick McHardy wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network
David Miller wrote:
From: Kirill Korotaev [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 12:14:29 +0400
David Miller wrote:
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK
message from kernel
First of all I managed to reproduce this bug with Gentoo LiveCD 2007.0 amd64
so now Im sure it is not Ubuntu specific. 2007.0 comes with kernel
2.6.19-gentoo-...
On Tuesday 05 of June 2007 22:37:09 you wrote:
Can you reproduce the problem if this module is not loaded at all ?
Please
On 6/7/07, Tej Parkash [EMAIL PROTECTED] wrote:
hi
i just want to have something like tcp layer sitting below inet layer.
so that i can directly offload everything to NIC
and i want it to be placed dynamically. so depending on the nic i can
offload the feature or can make it normal flow.
i.e.
so is it possible to unregister tcp and register my protocol dynamically.
inet_unregister_protosw()/inet_register_protosw().
oops...can't unregister tcp (permanent protocol).
-Kalash
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Thu, Jun 07 2007, Evgeniy Polyakov wrote:
On Wed, Jun 06, 2007 at 09:17:25AM +0200, Jens Axboe ([EMAIL PROTECTED])
wrote:
Some pages have zero reference counter here.
But it's somewhat annoying to get pages with zero reference counts
there, I wonder how that happens. I guess if the
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces
but it can be used as is as well.
Eric recently sent a similar driver
The usage is
# ip link add [name] type veth [peer name] [mac mac] [peer_mac mac]
This version doesn't include the fix for ip/iplink.c as Patrick
said that he had included it into his patches already.
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
---
diff --git a/ip/Makefile b/ip/Makefile
Hi All,
I will be sending bug fixes related to initialization, link status and
some compile issues of NetXen's 1/10G Ethernet driver in subsequent
mails.
These patches are wrt netdev#upstream-fixes.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line unsubscribe netdev in
NetXen: Fix incorrect link status even with switch turned OFF.
NetXen driver failed to accurately indicate when a link is up or down.
This was encountered during failover testing, when the first port
indicated that the link was up even when the 10G switch it was assigned
to in the Bladecenter
NetXen: Fix initialization and subsequent ping issue on 3.4.19 firmware
This patch fixes the ping problem seen X/PBlades after the adapter's
firmware was moved to 3.4.19. After configured interface up, ping
failed.
NetXen adapter couldn't accept ARP broadcast packet. Manual addition of
MAC
NetXen: Add multi cast filter code
This patch adds multi cast filter code to NetXen NIC driver.
It also adds capabilities to setup the multicast address in hardware
from the host side.
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 24 +
NetXen: Add NETXEN prefixes to macros to clean them up.
This is a cleanup patch which adds NETXEN prefix to some stand
alone macro names.
These posed compile errors when NetXen driver was backported to 2.6.9
on PPC architecture as macros like USER_START are defined in file
On Thu, 2007-07-06 at 11:46 +0530, Krishna Kumar2 wrote:
My somewhat confusing netperf script (to run on client) is attached below.
Server just requires
to run netserver. Client is not completely accurate since I am not using
netperf4 (moving to
that after some initial hiccups).
Thanks KK.
On Wed, 2007-06-06 at 21:08 -0400, jamal wrote:
It's too depressing - so i came back here for a break ;-
I am sure you would agree it was too depressing ;-
As a side note: You will have to do a lot of surgery to the current code
to make tx run on multi CPUs. It needs some experimenting to
On Wed, 2007-06-06 at 20:47 -0400, Jeff Garzik wrote:
1) you need (a) well-designed hardware _and_ (b) a smart driver writer
to avoid bottlenecking on internal driver locks. As you can see we have
both (a) and (b) for tg3 ;-)
How about the following patch which fixes #b for e1000 ;-
I
On Thu, 7 Jun 2007 20:40:39 +0900
Tetsuo Handa [EMAIL PROTECTED] wrote:
Hello.
Same local ports are assigned to multiple sockets.
The following program should print different local port number.
- Start of program -
#include stdio.h
#include unistd.h
#include sys/socket.h
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK
Deniel,
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the
Kirill Korotaev wrote:
Deniel,
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the etun name as well?
I
jamal wrote:
On Wed, 2007-06-06 at 20:47 -0400, Jeff Garzik wrote:
1) you need (a) well-designed hardware _and_ (b) a smart driver writer
to avoid bottlenecking on internal driver locks. As you can see we have
both (a) and (b) for tg3 ;-)
How about the following patch which fixes #b for
On Thu, Jun 07, 2007 at 12:51:59PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
What bout checking if page belongs to kmalloc cache (or any other cache
via priviate pointers) and do not perform any kind of reference counting
on them? I will play with this a bit later today.
That might
no one is against generic code and ability to create 2 interfaces in
*one* namespace.
(Like we currently allow to do so in OpenVZ)
However, believe me, moving an interface is a *hard* operation. Much
harder then netdev
register from the scratch.
Because it requires to take into account
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the
Two straight-forward, smallish patches against David's net-2.6 tree which fix
some kernel unaligned access errors/messages and remove some redundant code.
I've tested this patchset on both x86 and ia64 platforms and have not seen
any regressions.
I'm not sure about my timing, but if it is too
IPv4 options are not very well aligned within the packet and the format of a
CIPSO option is even worse. The result is that the CIPSO engine in the kernel
does a few unaligned accesses when parsing and validating incoming packets with
CIPSO options attached which generate error messages on
The current NetLabel code has some redundant APIs which allow both
struct socket and struct sock types to be used; this may have made sense at
some point but it is wasteful now. Remove the functions that operate on
sockets and convert the callers. Not only does this make the code smaller and
Pavel Emelianov wrote:
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the
Pavel Emelianov wrote:
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver
Rolf Eike Beer wrote:
You wrote:
Rolf Eike Beer [EMAIL PROTECTED] :
[...]
I just had another freeze using your patches. After 512kB over smb it
was dead.
In-kernel smb/cifs ?
Copying to a partition mounted via smb:// protocol in konqueror which uses
kio_smb (userspace io
On Thu, 07 Jun 2007 15:16:34 +0400
Pavel Emelianov [EMAIL PROTECTED] wrote:
The usage is
# ip link add [name] type veth [peer name] [mac mac] [peer_mac mac]
This version doesn't include the fix for ip/iplink.c as Patrick
said that he had included it into his patches already.
Ben Greear wrote:
Pavel Emelianov wrote:
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there
On Wed, 06 Jun 2007 16:56:02 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: jamal [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 19:35:46 -0400
There is no potential for parallelizing on transmit that i can think of.
Dave, please explain it slowly so i can understand it.
There is
On Thu, Jun 07, 2007 at 07:43:49AM -0400, jamal ([EMAIL PROTECTED]) wrote:
Folks, we need help. Please run this on different hardware. Evgeniy, i
thought this kind of stuff excites you, no? ;- (wink, wink).
Only the sender needs the patch but the receiver must be a more powerful
machine (so
On Tue, May 29, 2007 at 05:24:36PM -0700, Stephen Hemminger wrote:
It doesn't look like spidernet hardware can really checksum all protocols,
the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
instead of NETIF_F_HW_CSUM.
The driver doesn't need it's own get/set for
Pavel Emelianov wrote:
Hmm... The loopback must be doing bad things then. It first calls
eth_type_trans and then accounts for the new skb-len.
Perhaps it should be changed. e100 calculates the entire
frame as far as I can tell, and e1000 and tg3 do it in hardware
(not sure what all they are
If they have multiple TX queues, independantly programmable, that
single lock is stupid.
We could use per-queue TX locks for such hardware, but we can't
support that currently.
There could be bad packet reordering with this (like some SMP
routers used to do).
My original
It doesn't look like spidernet hardware can really checksum all protocols,
the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
instead of NETIF_F_HW_CSUM.
The driver doesn't need it's own get/set for ethtool tx csum, and it
should use the standard ethtool_op_get_link.
Jeff, please apply for the 2.6.23 kernel tree. The pach series
consists of two major bugfixes, and several bits of cleanup.
The major bug fixes are:
1) a rare but fatal bug involving RX ram full messages,
which results in a driver deadlock.
2) misconfigured TX interrupts, causing a sever
From: Florin Malita [EMAIL PROTECTED]
The stats update code in spider_net_pass_skb_up() is touching the skb
after it's been passed up to the stack. To avoid that, just update the
stats first.
Signed-off-by: Florin Malita [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
From: Stephen Hemminger [EMAIL PROTECTED]
It doesn't look like spidernet hardware can really checksum all protocols,
the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
instead of NETIF_F_HW_CSUM.
The driver doesn't need it's own get/set for ethtool tx csum, and it
Use dev_err() to print device error messages.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 67 ---
drivers/net/spider_net.h |2 -
2 files changed, 36 insertions(+), 33 deletions(-)
Index:
Put the enable and disable routines next to one-another,
as this makes verifying thier symmetry that much easier.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
Index:
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index:
If the ethernet interface is brought down while there is still
RX traffic in flight, the device shutdown routine can end up
trying to double-free an skb, leading to a crash in mm/slab.c
Avoid the double-free by nulling out the skb pointer.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Subject: [PATCH 7/18] spidernet: Don't terminate the RX ring
There is no real reason to terminate the RX ring; it
doesn't make the operation any smooother, and it does
require an extra sync. So don't do it.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 18
Crazy device problems are hard to debug, when one does not have
good trace info. This patch makes a major enhancement to the
device dump routine.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 78 ++-
1 file changed,
Some versions of the spider have a firmware bug, where the
RX ring sequencer goes crazy when the RX RAM on the device
fills up. Appearently the only viable wrkaround is a soft
reset of the card.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 15 +++
When entering the netdev poll routine, empty out the RX
chain first, before cleaning up the TX chain. This should
help avoid RX buffer overflows.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
Another way of minimizing the likelyhood of RX ram from overflowing
is to empty out the entire rx ring every chance we get. Change
the crazy watchdog timeout from 50 seconds to 3 seconds, while
we're here.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.h |9
The current error checking is flagging some perfectly normal, but
usually rare packets as being bad. Do not flag these packets.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
Index:
This patch fixes a rare deadlock that can occur when the kernel
is not able to empty out the RX ring quickly enough. Below follows
a detailed description of the bug and te fix.
As long as the OS can empty out the RX buffers at a rate faster than
the hardware can fill them, there is no problem.
Altough the previous patch resolved issues with hangs when the
RX ram full interrupt is encountered, there are still situations
where lots of RX ramfull interrupts arrive, rsulting in a noisy
log in syslog. There is no need for this.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
A minor optimization on the RX side is that the hardware does
not need to be kicked if space did not open up in the RX ring.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index:
The transmit frame tail bit is stranglely misnamed as
no checksum. Fix the name to what it should be:
transmit frame tail. No functional change,
just a name change.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |2 +-
drivers/net/spider_net.h |2 +-
2
At some point, the transmit descriptor chain end interrupt (TXDCEINT)
was turned on. This is a mistake; and it damages small packet
transmit performance, as it results in a huge storm of interrupts.
Turn it off.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.h |
Documentation for the spidernet driver.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Documentation/networking/spider_net.txt | 204
1 file changed, 204 insertions(+)
Index: linux-2.6.22-rc1/Documentation/networking/spider_net.txt
On Thu, 7 Jun 2007 11:25:30 -0700
Miles Lane [EMAIL PROTECTED] wrote:
Hi Andrew,
This might be some problem with my kernel configuration.
I added:
CONFIG_BONDING=y
# dhclient eth1
There is already a pid file /var/run/dhclient.pid with pid 134993416
Internet Systems Consortium DHCP
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 7 Jun 2007 15:18:39 +0200
Yes, this was discovered two days ago and David reverted four commits.
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=82c5fde20031375cd93fa5a247cf15603ea1f152
So it should probably be
On Thu, 2007-07-06 at 08:03 -0700, Kok, Auke wrote:
To prevent against multiple entries bumping head tail at the same time as
well
as overwriting the same entries in the tx ring (contention for
next_to_watch/next_to_clean)?
In current code that lock certainly doesnt protect those
On Thu, 2007-07-06 at 09:08 -0700, Stephen Hemminger wrote:
There could be bad packet reordering with this (like some SMP routers used to
do).
You can avoid re-ordering if you guarantee that related flows always
end up on the same CPU via say tc filters i.e i dont think just a 5
tuple
jamal wrote:
On Thu, 2007-07-06 at 08:03 -0700, Kok, Auke wrote:
To prevent against multiple entries bumping head tail at the same time as well
as overwriting the same entries in the tx ring (contention for
next_to_watch/next_to_clean)?
In current code that lock certainly doesnt protect
On Thu, 7 Jun 2007 17:46:09 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
I'm not able to bring an ethernet interface down and back
On 2007.06.07 13:15:59 -0700, Andrew Morton wrote:
On Thu, 7 Jun 2007 11:25:30 -0700
Miles Lane [EMAIL PROTECTED] wrote:
Hi Andrew,
This might be some problem with my kernel configuration.
I added:
CONFIG_BONDING=y
# dhclient eth1
There is already a pid file
On Thu, 2007-07-06 at 20:13 +0400, Evgeniy Polyakov wrote:
Actually I wonder where the devil lives, but I do not see how that
patchset can improve sending situation.
Let me clarify: there are two possibilities to send data:
1. via batched sending, which runs via queue of packets and performs
Rolf Eike Beer [EMAIL PROTECTED] :
[...]
fine. Even the next try with this file didn't produce a crash. What was
different on this tests was that I used the console instead of X (don't want
to munch up too many file systems). Any ideas?
X and friends ?
Can you send the usual dmesg, lspci
On Thu, 2007-07-06 at 15:06 -0700, Kok, Auke wrote:
the contention isn't between multiple tx attempts, but between e1000_clean
and
tx.
I got you the first time but i think i am missing something: given that
the lock is used only on tx - how is that protecting the contention
between tx and
jamal wrote:
On Thu, 2007-07-06 at 15:06 -0700, Kok, Auke wrote:
the contention isn't between multiple tx attempts, but between e1000_clean and
tx.
I got you the first time but i think i am missing something: given that
the lock is used only on tx - how is that protecting the contention
Hello,
I have a machine on which I have an applications that sends multicast
through eth interface with hardware tx checksum enabled. On the same
machine I have mrouted running that routes the multicast traffic to a
set of ppp interfaces. The packets that are received by the client have
On Wed, 2007-06-06 at 09:49 -0400, jamal wrote:
If you help out, when you post your results, can you please say what
hardware and setup was?
Ok, i have tested on new hardware with pktgen:
Machine: Dual Xeon processor with EMT64 - kernel is 32 bit.
Chipset: E7520 Memory Controller Hub (MCH).
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 17:57:25 -0400
I empathize but take a closer look; seems mostly useless.
I thought E1000 still uses LLTX, and if so then multiple cpus can most
definitely get into the -hard_start_xmit() in parallel.
-
To unsubscribe from this list: send the
On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 17:57:25 -0400
I empathize but take a closer look; seems mostly useless.
I thought E1000 still uses LLTX, and if so then multiple cpus can most
definitely get into the
On Thu, Jun 07, 2007 at 03:06:53PM -0700, Andrew Morton wrote:
I'm not able to bring an ethernet interface down and back up again
with this if avahi-autoipd is installed on my Ubuntu boxes. I've seen
it on three different computers with different NIC hardware.
Sorry, it was my patch.
I empathize but take a closer look; seems mostly useless.
I thought E1000 still uses LLTX, and if so then multiple cpus
can most definitely get into the -hard_start_xmit() in parallel.
Not with how the qdisc status protects it today:
include/net/pkt_sched.h:
static inline void
On Thu, 2007-07-06 at 15:30 -0700, Kok, Auke wrote:
our rx interrupt/clean can trigger tx cleans, reaching the same code...
I see that - What i am saying is tx_lock never protects that.
Am i mistaken? i.e
CPU0 entering tx and and CPU1 entering rx interupt/clean can not be
blocked from each
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 18:54:08 -0400
On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 17:57:25 -0400
I empathize but take a closer look; seems mostly useless.
I thought E1000 still uses LLTX,
On Thu, 2007-07-06 at 16:00 -0700, David Miller wrote:
That's right we fixed that the other week.
Circa 2.6.18 to be exact - Hence In Pursuit of Herbert Xu ;-
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 2007-06-07 at 16:00 -0700, David Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 18:54:08 -0400
On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Thu, 07 Jun 2007 17:57:25 -0400
I empathize but take a closer
On Thu, 7 Jun 2007, Paul Moore wrote:
The current NetLabel code has some redundant APIs which allow both
struct socket and struct sock types to be used; this may have made sense
at
some point but it is wasteful now. Remove the functions that operate on
sockets and convert the callers. Not
On Thu, 2007-06-07 at 14:17 -0500, Linas Vepstas wrote:
Jeff, please apply for the 2.6.23 kernel tree. The pach series
consists of two major bugfixes, and several bits of cleanup.
The major bug fixes are:
1) a rare but fatal bug involving RX ram full messages,
which results in a
On Thu, 7 Jun 2007, Paul Moore wrote:
IPv4 options are not very well aligned within the packet and the format of a
CIPSO option is even worse. The result is that the CIPSO engine in the kernel
does a few unaligned accesses when parsing and validating incoming packets
with
CIPSO options
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 10:08:29 +0200
There are races involving the garbage collector, that can throw away
perfectly good packets with AF_UNIX sockets in them.
The problems arise when a socket goes from installed to in-flight or
vice versa during
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 8 Jun 2007 08:54:52 +1000
On Thu, Jun 07, 2007 at 03:06:53PM -0700, Andrew Morton wrote:
I'm not able to bring an ethernet interface down and back up again
with this if avahi-autoipd is installed on my Ubuntu boxes. I've seen
it on
On Thu, 2007-07-06 at 17:31 -0700, Sridhar Samudrala wrote:
If the QDISC_RUNNING flag guarantees that only one CPU can call
dev-hard_start_xmit(), then why do we need to hold netif_tx_lock
for non-LLTX drivers?
I havent stared at other drivers, but for e1000 seems to me
even if you got rid
From: James Morris [EMAIL PROTECTED]
Date: Thu, 7 Jun 2007 21:18:26 -0400 (EDT)
On Thu, 7 Jun 2007, Paul Moore wrote:
The current NetLabel code has some redundant APIs which allow both
struct socket and struct sock types to be used; this may have made
sense at
some point but it is
From: James Morris [EMAIL PROTECTED]
Date: Thu, 7 Jun 2007 21:20:20 -0400 (EDT)
On Thu, 7 Jun 2007, Paul Moore wrote:
IPv4 options are not very well aligned within the packet and the format of a
CIPSO option is even worse. The result is that the CIPSO engine in the
kernel
does a few
Hi Evgeniy,
Let me clarify: there are two possibilities to send data:
1. via batched sending, which runs via queue of packets and performs
prepare call (which only setups some private flags, no work with
hardware) and then sending call.
2. old xmit function (which seems to be unused by
1 - 100 of 102 matches
Mail list logo
