On Mon, 01 Oct 2007 15:15:59 -0600
"Chris Friesen" <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
>
> > Adding fragmentation support to skge driver is on my list of
> > possible extensions. sky2 driver already supports it (yet one
> > more feature that the vendor sk98lin driver doesn't do)
Jeff Garzik wrote:
The sk98lin driver is going away, please don't use it.
It's unmaintained and full of known bugs.
Okay...so it looks like the proper driver for the Marvell Yukon 88E8062
is the sky2 driver, and this one does avoid order>0 allocations. Am I
on track?
Chris
-
To unsubscri
Stephen Hemminger wrote:
Adding fragmentation support to skge driver is on my list of
possible extensions. sky2 driver already supports it (yet one
more feature that the vendor sk98lin driver doesn't do).
Thanks for speaking up. As I mentioned in my email to Jeff it looks
like the sky2 drive
On Mon, 01 Oct 2007 14:35:48 -0600
"Chris Friesen" <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> We're considering some hardware that uses the sk98lin network hardware,
> and we'll be using jumbo frames. Looking at the driver, when using a
> 9KB MTU it seems like it would end up trying to atomic
Chris Friesen wrote:
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end up trying to atomically allocate a
16KB buffer.
The sk98lin driver is going away, please don't
Yes it has this problem. I've observed it in practice on a busy firewall.
-John
Chris Friesen wrote:
Hi all,
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end u
Hi all,
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end up trying to atomically allocate a
16KB buffer.
Has anyone heard of this been a problem? It would seem li
Herbert Xu wrote:
Chris Friesen <[EMAIL PROTECTED]> wrote:
Looking at the page-splitting code, it says "82571 and greater support
packet-split...". We're running the 82546GB device. Looks like it
won't help me.
Well, time to fork out for a new card then :)
I wish. This is an embedded
Chris Friesen <[EMAIL PROTECTED]> wrote:
> Herbert Xu wrote:
>
>> Either upgrade your kernel or backport the page-splitting code in the
>> current tree. That's really the only sane solution for jumbo packets.
>
> Looking at the page-splitting code, it says "82571 and greater support
> packet-sp
On Fri, Jun 30, 2006 at 05:35:34PM -0600, Chris Friesen ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
>
> >It definitely will.
> >Packet split in hardware means separating data and headers into
> >different pages in different reads, while software page split means that
> >skb has a list o
On 6/30/06, Chris Friesen <[EMAIL PROTECTED]> wrote:
Evgeniy Polyakov wrote:
> It definitely will.
> Packet split in hardware means separating data and headers into
> different pages in different reads, while software page split means that
> skb has a list of fragments where part of the packet w
Evgeniy Polyakov wrote:
It definitely will.
Packet split in hardware means separating data and headers into
different pages in different reads, while software page split means that
skb has a list of fragments where part of the packet will be DMAed, so
jumbo frame will be converted into several
On Fri, Jun 30, 2006 at 11:53:36AM -0600, Chris Friesen ([EMAIL PROTECTED])
wrote:
> >Either upgrade your kernel or backport the page-splitting code in the
> >current tree. That's really the only sane solution for jumbo packets.
>
> Looking at the page-splitting code, it says "82571 and greater
Herbert Xu wrote:
Either upgrade your kernel or backport the page-splitting code in the
current tree. That's really the only sane solution for jumbo packets.
Looking at the page-splitting code, it says "82571 and greater support
packet-split...". We're running the 82546GB device. Looks lik
Chris Friesen <[EMAIL PROTECTED]> wrote:
>
> Anyone have any suggestions on how to improve this? Upgrading kernels
> isn't an option. I could port back the copybreak stuff fairly easily.
Either upgrade your kernel or backport the page-splitting code in the
current tree. That's really the only
I'm running a system with multiple e1000 devices, using 9KB jumbo
frames. I'm running a modified 2.6.10 with e1000 driver 5.5.4-k2.
I'm a bit concerned about the behaviour of this driver with jumbo
frames. We ask for 9KB. The driver then bumps that up to a
power-of-two, so it calls dev_al
16 matches
Mail list logo
