netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* sk98lin, jumbo frames, and memory fragmentation
@ 2007-10-01 20:35 Chris Friesen
  2007-10-01 20:44 ` John Heffner
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Chris Friesen @ 2007-10-01 20:35 UTC (permalink / raw)
  To: linux, netdev


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 like trying to 
atomically allocate four physically contiguous pages could become tricky 
after the system has been running for a while.

The reason I ask is that we ran into this with the e1000.  Before they 
added the new jumbo frame code it was trying to atomically allocate 32KB 
buffers and we would start getting allocation failures after a month or 
so of uptime.

Any information anyone can provide would be appreciated.


Thanks,

Chris

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 20:35 sk98lin, jumbo frames, and memory fragmentation Chris Friesen
@ 2007-10-01 20:44 ` John Heffner
  2007-10-01 20:47 ` Jeff Garzik
  2007-10-01 21:06 ` Stephen Hemminger
  2 siblings, 0 replies; 7+ messages in thread
From: John Heffner @ 2007-10-01 20:44 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linux, netdev

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 up trying to atomically allocate a 
> 16KB buffer.
> 
> Has anyone heard of this been a problem?  It would seem like trying to 
> atomically allocate four physically contiguous pages could become tricky 
> after the system has been running for a while.
> 
> The reason I ask is that we ran into this with the e1000.  Before they 
> added the new jumbo frame code it was trying to atomically allocate 32KB 
> buffers and we would start getting allocation failures after a month or 
> so of uptime.
> 
> Any information anyone can provide would be appreciated.
> 
> 
> Thanks,
> 
> Chris
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 20:35 sk98lin, jumbo frames, and memory fragmentation Chris Friesen
  2007-10-01 20:44 ` John Heffner
@ 2007-10-01 20:47 ` Jeff Garzik
  2007-10-01 21:08   ` Chris Friesen
  2007-10-01 21:06 ` Stephen Hemminger
  2 siblings, 1 reply; 7+ messages in thread
From: Jeff Garzik @ 2007-10-01 20:47 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linux, netdev

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 use it.

It's unmaintained and full of known bugs.

	Jeff




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 20:35 sk98lin, jumbo frames, and memory fragmentation Chris Friesen
  2007-10-01 20:44 ` John Heffner
  2007-10-01 20:47 ` Jeff Garzik
@ 2007-10-01 21:06 ` Stephen Hemminger
  2007-10-01 21:15   ` Chris Friesen
  2 siblings, 1 reply; 7+ messages in thread
From: Stephen Hemminger @ 2007-10-01 21:06 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linux, netdev

On Mon, 01 Oct 2007 14:35:48 -0600
"Chris Friesen" <cfriesen@nortel.com> 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 atomically allocate a 
> 16KB buffer.
> 
> Has anyone heard of this been a problem?  It would seem like trying to 
> atomically allocate four physically contiguous pages could become tricky 
> after the system has been running for a while.
> 
> The reason I ask is that we ran into this with the e1000.  Before they 
> added the new jumbo frame code it was trying to atomically allocate 32KB 
> buffers and we would start getting allocation failures after a month or 
> so of uptime.
> 
> Any information anyone can provide would be appreciated.

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).

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 20:47 ` Jeff Garzik
@ 2007-10-01 21:08   ` Chris Friesen
  0 siblings, 0 replies; 7+ messages in thread
From: Chris Friesen @ 2007-10-01 21:08 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux, netdev

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 21:06 ` Stephen Hemminger
@ 2007-10-01 21:15   ` Chris Friesen
  2007-10-01 21:57     ` Stephen Hemminger
  0 siblings, 1 reply; 7+ messages in thread
From: Chris Friesen @ 2007-10-01 21:15 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: linux, netdev

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 driver is what I need (Marvel Yukon 88E8062).  However, 
I'm on 2.6.14 and it doesn't exist there...do you anticipate any issues 
if I were to backport it?

Thanks,

Chris

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sk98lin, jumbo frames, and memory fragmentation
  2007-10-01 21:15   ` Chris Friesen
@ 2007-10-01 21:57     ` Stephen Hemminger
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Hemminger @ 2007-10-01 21:57 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linux, netdev

On Mon, 01 Oct 2007 15:15:59 -0600
"Chris Friesen" <cfriesen@nortel.com> 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).
> 
> Thanks for speaking up.  As I mentioned in my email to Jeff it looks 
> like the sky2 driver is what I need (Marvel Yukon 88E8062).  However, 
> I'm on 2.6.14 and it doesn't exist there...do you anticipate any issues 
> if I were to backport it?

Nothing but usual annoying kernel API changes..


-- 
Stephen Hemminger <shemminger@linux-foundation.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-10-01 21:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-01 20:35 sk98lin, jumbo frames, and memory fragmentation Chris Friesen
2007-10-01 20:44 ` John Heffner
2007-10-01 20:47 ` Jeff Garzik
2007-10-01 21:08   ` Chris Friesen
2007-10-01 21:06 ` Stephen Hemminger
2007-10-01 21:15   ` Chris Friesen
2007-10-01 21:57     ` Stephen Hemminger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).