netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: vinay ravuri <vinaynyc@yahoo.com>
Cc: netdev@vger.kernel.org
Subject: Re: Socket Buffers and Memory Managment
Date: Tue, 17 Jul 2007 20:41:29 +0100	[thread overview]
Message-ID: <20070717204129.79e7fe0d@oldman> (raw)
In-Reply-To: <551531.35231.qm@web82912.mail.mud.yahoo.com>

On Tue, 17 Jul 2007 10:20:58 -0700 (PDT)
vinay ravuri <vinaynyc@yahoo.com> wrote:

> Hi,
> 
> I am fairly new to linux socket buffers and have the
> following questions!
> 
> I am working with a custom ethernet MAC that does not
> allow me to specify a particular memory location for
> the h/w to DMA the packet into (Rx side).  Instead, it
> has a pool of fixed size buffers with some h/w
> specific headers around each buffer that are managed
> by h/w and will pick a free buffer and DMA the packet.

Sounds like sucky hardware...
You need to copy to a newly allocated skb, see 8139too.c

>  It appears dev_alloc_skb() actually allocates the
> physical memory and doesn't allow the user to specify
> the skb.data to something specific to what I want
> which is a problem for me.  First is my assumption
> correct that I am cannot pick an arbitrary skb.data
> location in struct sk_buff?  I want to avoid copying
> the dma'ed data into a new socket buffer as it is
> expense.  Is there any ways around this problem?

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.
 
> Also, if the h/w gives me a single packet in multiple
> locations (i.e. non-contiguous chunks of memory), can
> socket buffers handle chains of buffers?  I am looking
> for a facility like mbuf's in netbsd where one can
> chain multiple buffers together to make construct a
> single packet.

Yes, skb frag list could be used for that but you don't
want to do that. See above. Copy the data into an new
skb and reserve any necessary bytes so IP header is
aligned.  I.e. if using ethernet header (14 bytes), do
skb_reserve(skb, 2) before copying the data.

  reply	other threads:[~2007-07-17 19:41 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 [this message]
2007-07-17 19:44   ` David Miller
2007-07-18 17:13   ` Roy Pledge
2007-07-18 21:22     ` Stephen Hemminger
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=20070717204129.79e7fe0d@oldman \
    --to=shemminger@linux-foundation.org \
    --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).