From: Kazunori Miyazawa <[EMAIL PROTECTED]>
Date: Fri, 09 Dec 2005 13:20:14 +0900
> 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 pha
On Thu, Dec 08, 2005 at 04:13:52PM -0600, Kumar Gala ([EMAIL PROTECTED]) wrote:
> 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,
> > >
> > >
> >
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 would
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
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 capabi
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
rea
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 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
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 car
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 does it really m
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
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 str
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, par
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 hand
David S. Miller writes:
> BTW, this is all related to SKB recycling.
>
> 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(). :-)
Sounds very nice...
Cheers.
jamal writes:
> Good news to the intel folks: My results agree yours this time.
> Robert, could you double check on opterons?
> #1, #2, and #5 _with copybreak_ turned on gave the best results. I got
> about the same results as with all turned on +/- a few pps which could
> be attributed to
> 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 [EMA
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 ne
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
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 PRO
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 Ber
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
t
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:
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
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
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_ALIG
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);
> >
> > b
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 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
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 se
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 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
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 o
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 sent
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
> 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
> unneces
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
(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
netif_receive_skb_c
On Wed, 7 Dec 2005 14:34:22 +0100, Michael Buesch wrote:
> I agree with you, and that is exactly what we are doing:
> We take the existing code and add functionality to it. If the
> added functionality is an external module, well, consinder this
> as an extra cookie for devices which do not need MA
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
> > netif_receive_skb_cpybrk() which tells driver if skb is consumed or not.
>
> It is not
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 soc
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 w
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 f
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 lo
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
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 a
46 matches
Mail list logo
