From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Roy Pledge <Roy.Pledge@freescale.com>
Cc: vinay ravuri <vinaynyc@yahoo.com>, netdev@vger.kernel.org
Subject: Re: Socket Buffers and Memory Managment
Date: Wed, 18 Jul 2007 22:22:40 +0100 [thread overview]
Message-ID: <20070718222240.7fd519a7@oldman> (raw)
In-Reply-To: <469E4A31.6030603@freescale.com>
On Wed, 18 Jul 2007 13:13:21 -0400
Roy Pledge <Roy.Pledge@freescale.com> wrote:
> Stephen Hemminger wrote:
> >
> > You could play tricks with skb frags but it would be fragile
> > and not worth the trouble. The problem is that the receive
> > skb can stay in the system for a really long time (until the application
> > reads the data) so your fixed size buffer pool in hardware
> > would get exhausted.
> >
> Perhaps you could elaborate on why this is considered fragile? It seems to me
> that as long as proper page management is performed, this mechanism should be
> stable for processing non-contiguous receive buffers. I agree that
> replenishment needs to be addressed, but I see that as an independent issue from
> using frag lists on receive.
Imagine you had a 4MB receive area. If you used fraglist to point to
the data area, you would still be at risk of receive lock up when you have
all the receive area used up in skb's waiting in the receive queue of the
sockets. You might get it to work if the receive are was very large (ie much
larger than tcp_rmem), but at that point you might as well as be able
to access all of system memory.
Using a DMA I/O engine would help, but you probably won't have one available.
next prev parent reply other threads:[~2007-07-18 21:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-17 17:20 Socket Buffers and Memory Managment vinay ravuri
2007-07-17 19:41 ` Stephen Hemminger
2007-07-17 19:44 ` David Miller
2007-07-18 17:13 ` Roy Pledge
2007-07-18 21:22 ` Stephen Hemminger [this message]
2007-07-19 6:51 ` vinay ravuri
2007-07-19 7:04 ` pradeep singh
2007-07-19 8:10 ` Stephen Hemminger
2007-07-19 9:08 ` Evgeniy Polyakov
2007-07-20 11:50 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070718222240.7fd519a7@oldman \
--to=shemminger@linux-foundation.org \
--cc=Roy.Pledge@freescale.com \
--cc=netdev@vger.kernel.org \
--cc=vinaynyc@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).