From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: "Jiafei.Pan@freescale.com" <Jiafei.Pan@freescale.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
"jkosina@suse.cz" <jkosina@suse.cz>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"LeoLi@freescale.com" <LeoLi@freescale.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH] net: use hardware buffer pool to allocate skb
Date: Thu, 16 Oct 2014 08:28:19 -0700 [thread overview]
Message-ID: <543FE413.6030406@redhat.com> (raw)
In-Reply-To: <aeef795129504782ae1e9f91467d243e@BLUPR03MB517.namprd03.prod.outlook.com>
On 10/15/2014 10:15 PM, Jiafei.Pan@freescale.com wrote:
>> -----Original Message-----
>> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>> Sent: Thursday, October 16, 2014 12:15 PM
>> To: Pan Jiafei-B37022
>> Cc: David Miller; jkosina@suse.cz; netdev@vger.kernel.org; Li Yang-Leo-R58472;
>> linux-doc@vger.kernel.org
>> Subject: Re: [PATCH] net: use hardware buffer pool to allocate skb
>>
>> On Thu, 2014-10-16 at 02:17 +0000, Jiafei.Pan@freescale.com wrote:
>>
>>> Thanks for your comments and suggestion. In my case, I want to build skb
>>> from hardware block specified memory, I only can see two ways, one is modified
>>> net card driver replace common skb allocation function with my specially
>>> functions, another way is to hack common skb allocation function in which
>>> redirect to my specially functions. My patch is just for the second way.
>>> Except these two ways, would you please give me some advice for some other
>>> ways for my case? Thanks
>> I suggest you read drivers/net/ethernet numerous examples.
>>
>> No need to change anything in net/* or include/*, really.
>>
>> For a start, look at drivers/net/ethernet/intel/igb/igb_main.c
>>
>> Mentioning 'hack' in your mails simply should hint you are doing
>> something very wrong.
>>
>> What makes you think your hardware is so special ?
>>
> In fact, I am developing a bridge driver, it can bridge between any other the
> third party net card and my own net card. My target is to let any other the
> third party net card can directly use my own net card specified buffer, then
> there will be no memory copy in the whole bridge process.
> By the way, I don’t see any similar between igb_main.c and my case. And also
> My bridge also can’t implemented with "skb frag" in order to aim at zero memory
> copy.
I think the part you are not getting is that is how buffers are
essentially handled now. So for example in the case if igb the only
part we have copied out is usually the header, or the entire frame in
the case of small packets. This has to happen in order to allow for
changes to the header for routing and such. Beyond that the frags that
are passed are the buffers that igb is still holding onto. So
effectively what the other device transmits in a bridging/routing
scenario is my own net card specified buffer plus the copied/modified
header.
For a brief period igb used build_skb but that isn't valid on most
systems as memory mapped for a device can be overwritten if the page is
unmapped resulting in any changes to the header for routing/bridging
purposes being invalidated. Thus we cannot use the buffers for both the
skb->data header which may be changed and Rx DMA simultaneously.
Thanks,
Alex
next prev parent reply other threads:[~2014-10-16 15:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 3:26 [PATCH] net: use hardware buffer pool to allocate skb Pan Jiafei
2014-10-15 4:15 ` Eric Dumazet
2014-10-15 4:26 ` David Miller
2014-10-15 5:43 ` Jiafei.Pan
2014-10-15 9:15 ` Eric Dumazet
2014-10-15 4:25 ` David Miller
2014-10-15 5:34 ` Jiafei.Pan
2014-10-15 9:15 ` Eric Dumazet
2014-10-16 2:17 ` Jiafei.Pan
2014-10-16 4:15 ` Eric Dumazet
2014-10-16 5:15 ` Jiafei.Pan
2014-10-16 15:28 ` Alexander Duyck [this message]
2014-10-16 16:57 ` Eric Dumazet
2014-10-16 17:10 ` Alexander Duyck
2014-10-16 17:45 ` Eric Dumazet
2014-10-16 18:20 ` Alexander Duyck
2014-10-16 21:40 ` Eric Dumazet
2014-10-16 22:12 ` Alexander Duyck
2014-10-17 9:11 ` David Laight
2014-10-17 14:40 ` Alexander Duyck
2014-10-17 16:55 ` Eric Dumazet
2014-10-17 18:28 ` Alexander Duyck
2014-10-17 18:53 ` Eric Dumazet
2014-10-18 0:26 ` Eric Dumazet
2014-10-17 19:02 ` Eric Dumazet
2014-10-17 19:38 ` Alexander Duyck
2014-10-17 19:51 ` Eric Dumazet
2014-10-17 22:13 ` Alexander Duyck
2014-10-17 2:35 ` Jiafei.Pan
2014-10-17 14:05 ` Eric Dumazet
2014-10-17 14:12 ` Alexander Duyck
2014-10-16 2:17 ` Jiafei.Pan
2014-10-15 15:51 ` David Miller
2014-10-15 4:59 ` Oliver Hartkopp
2014-10-15 5:47 ` Jiafei.Pan
2014-10-15 8:57 ` David Laight
2014-10-15 9:33 ` Stephen Hemminger
2014-10-16 2:30 ` Jiafei.Pan
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=543FE413.6030406@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=Jiafei.Pan@freescale.com \
--cc=LeoLi@freescale.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-doc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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).