David S. Miller writes:
For the host bound case, copybreak is always a way due to how
socket buffer accounting works. If you use a 1500 byte SKB for
64 bytes of data, this throws off all of the socket buffer
accounting because you're consuming more of the socket limit
per byte of data
From: John Heffner [EMAIL PROTECTED]
Date: Tue, 06 Dec 2005 14:42:53 -0500
I'd like to get a few people at least to look this over, and maybe give
it a try. One remaining item to consider is how best to cache the state
between connections. Are there any major concerns or reservations about
From: Robert Olsson [EMAIL PROTECTED]
Date: Thu, 8 Dec 2005 10:20:43 +0100
Why not remove copybreak from the drivers and do eventual copybreak after we
have looked up the packet. This way we can get copybreak for all drivers and
we can do this only for packets with has destination to
On Thu, Dec 08, 2005 at 01:35:11AM -0800, David S. Miller wrote:
From: Robert Olsson [EMAIL PROTECTED]
Date: Thu, 8 Dec 2005 10:20:43 +0100
Why not remove copybreak from the drivers and do eventual copybreak after
we
have looked up the packet. This way we can get copybreak for all
From: Andi Kleen [EMAIL PROTECTED]
Date: Thu, 8 Dec 2005 10:39:25 +0100
The problem is that there can be a quite long per CPU queue already
before lookup - and without copybreak a lot of memory might
be wasted in there.
There is no queue, we go straight from driver RX handling
all the way
Robert Olsson a écrit :
David S. Miller writes:
For the host bound case, copybreak is always a way due to how
socket buffer accounting works. If you use a 1500 byte SKB for
64 bytes of data, this throws off all of the socket buffer
accounting because you're consuming more of the socket
(05.12.08 kl.10:56) Eric Dumazet skrev följande till Robert Olsson:
Robert Olsson a écrit :
David S. Miller writes:
This will lead to an extra alloc in case of copybreak but it could
possible to avoid this with some function giving copybreak feedback to
driver i.e via
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
Unfortunately, the only long-term solution is to rewrite completely the
current in-kernel ieee80211 code (I would not call it a stack) or
replace it with something another. The current code was written for
Intel devices and it doesn't
3. Most of WE calls can be handled by ieee80211 itself. The rest should
be propagated to a driver in some easier way than requiring driver to
deal with the whole WE stuff itself. Also, exporting callbacks from
ieee80211 that driver has to set as particular WE handlers seems to be
unnecessary
On Thu, 08 Dec 2005 13:12:44 +0100, Arjan van de Ven wrote:
this argument is analogue to the adaptec SAS driver one about the scsi
host structure. ieee80211 should be a LIBRARY of functions that can do
things,
Unfortunately, it is not possible to implement ieee80211 as a library,
because you
Hi!
I have a problem with kernel's behavior when receiving ESP/AH packets
with unknown SPI values.
As it turns out, when such a packet arrives, kernel simply discards it.
The consequence is that in some tests first packet is lost. For example,
trying to ping other side the 0th packet will be
On Thu, 8 Dec 2005, Stjepan Gros wrote:
I have a problem with kernel's behavior when receiving ESP/AH packets
with unknown SPI values.
As it turns out, when such a packet arrives, kernel simply discards it.
The consequence is that in some tests first packet is lost. For example,
trying to ping
On Thu, 2005-12-08 at 15:42 +0200, Pekka Savola wrote:
On Thu, 8 Dec 2005, Stjepan Gros wrote:
I have a problem with kernel's behavior when receiving ESP/AH packets
with unknown SPI values.
As it turns out, when such a packet arrives, kernel simply discards it.
The consequence is that
Hi, Ben
We used to have problems with X6DVA-EG2 and 4-port pro/1000
NIC from Silicom. Adding noapic and tweaking BIOS configuration
solved them. We've configured both Slot 5 and Slot 6 to 100Mhz.
We also have dual port pro/1000 NIC from Silicom, and I think it
works OK in both slots. The kernel
On Wed, 2005-07-12 at 16:11 -0800, David S. Miller wrote:
From: John Ronciak [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 16:09:21 -0800
On 12/7/05, David S. Miller [EMAIL PROTECTED] wrote:
I think Jesse's data and recommendation of only keeping the #1, #2
and #5 prefetches seem like the
On Wed, 2005-07-12 at 23:04 +0100, Eric Dumazet wrote:
David S. Miller a écrit :
Another try could be to do some benchmarks about NET_IP_ALIGN being a valid
optimization nowadays :
Maybe setting it to 0 in e1000 driver could give better results.
Could somebody give it a try ?
Ok, I tried
Felix Radensky wrote:
Hi, Ben
We used to have problems with X6DVA-EG2 and 4-port pro/1000
NIC from Silicom. Adding noapic and tweaking BIOS configuration
solved them. We've configured both Slot 5 and Slot 6 to 100Mhz.
We also have dual port pro/1000 NIC from Silicom, and I think it
works OK in
On 12/7/05, David S. Miller [EMAIL PROTECTED] wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 08 Dec 2005 04:47:05 +0100
#4#5 as proposed in the patch can not be a win
+ prefetch(next_skb);
+ prefetch(next_skb-data - NET_IP_ALIGN);
because at the time
Jesse Brandeburg a écrit :
On 12/7/05, David S. Miller [EMAIL PROTECTED] wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 08 Dec 2005 04:47:05 +0100
#4#5 as proposed in the patch can not be a win
+ prefetch(next_skb);
+ prefetch(next_skb-data - NET_IP_ALIGN);
Having it off by default is a bad idea from a socket perspective.
When you have 64 byte data packets consuming 1500+ bytes of
data storage, which is what you get with copybreak disabled,
TCP spends all of it's time copying packet data around as the
socket buffering limits on receive are hit quite
Thanks regards,
Utz
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
We changed the name of the Kconfig symbols along with
the move to arch/powerpc. This one hunk got lost during
the conversion.
From: Jens Osterkamp [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Signed-off-by: Utz Bacher [EMAIL PROTECTED]
Index:
request_firmware() is sometimes problematic, especially
in initramfs, reading the firmware from Open Firmware
is much preferrable.
We still try to get the firmware from the file system
first, in order to support old SLOF releases and to allow
updates of the spidernet firmware without reflashing
The driver incorrectly used dma_addr_t to describe
HW structures and consequently broke when that type
was changed in 2.6.15-rc.
This changed spidernet to use u32 for 32 bit HW defined
structure elements.
From: Jens Osterkamp [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd
Performance optimizations, changes in these areas:
- RX and TX checksum offload
- correct maximum MTU
- don't use TX interrupts anymore, use a timer instead
- remove some superfluous barriers
- improve RX RAM full handling
From: Utz Bacher [EMAIL PROTECTED]
From: Jens Osterkamp [EMAIL
Oopsie... my mailer was going off too fast. I was going to say:
This set of patches against 2.6.15-rc5 updates spider_net at various
places. Please consider for inclusion.
Sorry for the hickup -- thanks regards,
Utz
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
From: Robert Olsson [EMAIL PROTECTED]
Date: Thu, 8 Dec 2005 11:35:06 +0100
David S. Miller writes:
It is not clear if we want to wait the whole netif_receive_skb()
execution to get this status. That can take a long time to execute
:-)
The driver has to wait for full
For example, if this is just a TCP ACK, we can do better than
copybreak and just let the driver use the SKB again upon
return from netif_receive_skb(). :-)
That's a cool optimization.
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Wed, 23 Nov 2005, Jeff Garzik wrote:
Alan Cox wrote:
Additionally, current IOAT is memory-memory. I would love to be able
to convince Intel to add transforms and checksums,
Not just transforms but also masks and maybe even merges and textures
would be rather handy 8)
Ah
Kumar I'm actually searching for any examples of drivers that
Kumar deal with the issues related to DMA'ng directly two and
Kumar from user space memory.
It's not quite the same story as what you're doing with DMA engines
inside the CPU, but you could look at drivers/infiniband,
On Iau, 2005-12-08 at 16:13 -0600, Kumar Gala wrote:
I'm actually searching for any examples of drivers that deal with the
issues related to DMA'ng directly two and from user space memory.
Look at drivers/media/video for several examples. Essentially in 2.6
get_user_pages() gives you page
On Fri, 02 Dec 2005 20:02:10 -0800 (PST)
David S. Miller [EMAIL PROTECTED] wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 03 Dec 2005 09:59:31 +1100
Sorry but I disagree. First of all this is inside a net_ratelimit() so
DoS potentials are well, limited :)
More importantly, you
From: Francois Romieu [EMAIL PROTECTED]
Date: Fri, 9 Dec 2005 00:09:47 +0100
Rick Jones [EMAIL PROTECTED] :
[...]
Does it really need to be particularly aggressive about that? How often
are there great streams of small packets sitting in a socket buffer? One
really only cares when the
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 8 Dec 2005 14:58:20 -0800
The problem I was seeing turned out to be that skb-dev is NULL when
the checksum is being completed in user context. This happens because the
reference to the device is dropped (to allow it to be released when
Francois Romieu wrote:
Rick Jones [EMAIL PROTECTED] :
[...]
Does it really need to be particularly aggressive about that? How often
are there great streams of small packets sitting in a socket buffer? One
really only cares when the system starts getting memory challenged right?
Until then
David S. Miller wrote:
From: Francois Romieu [EMAIL PROTECTED]
Date: Fri, 9 Dec 2005 00:09:47 +0100
Rick Jones [EMAIL PROTECTED] :
[...]
Does it really need to be particularly aggressive about that? How often
are there great streams of small packets sitting in a socket buffer? One
really
Since upgrading my kernel from 2.6.11.7 to 2.6.12.2 (and also with
2.6.13 and now 2.6.14.3), I've been experiencing a variable delay
when booting of 0 to 60 seconds before seeing the following message
and being able to use the network:
eth0: Setting full-duplex based on MII #0 link partner
Ben Greear wrote:
Felix Radensky wrote:
Hi, Ben
We used to have problems with X6DVA-EG2 and 4-port pro/1000
NIC from Silicom. Adding noapic and tweaking BIOS configuration
solved them. We've configured both Slot 5 and Slot 6 to 100Mhz.
We also have dual port pro/1000 NIC from Silicom, and I
Hello David and Herbert,
I send a patch to fix pmtu calculation of IPv6 ESP.
It is a simple bug which uses the wrong member.
This bug does not seriously affect ordinary use of IPsec.
But it is important to pass IPv6 ready logo phase-2
conformance test of IPsec SGW.
I will appreciate if you
39 matches
Mail list logo
