From: Li Yu <raise.sail@gmail•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Linux Netdev List <netdev@vger•kernel.org>
Subject: Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
Date: Fri, 09 Nov 2012 10:31:11 +0800 [thread overview]
Message-ID: <509C6AEF.4020300@gmail.com> (raw)
In-Reply-To: <1352381449.19779.13.camel@edumazet-glaptop>
于 2012年11月08日 21:30, Eric Dumazet 写道:
> On Thu, 2012-11-08 at 15:46 +0800, Li Yu wrote:
>
>> I think that all kmalloced() objects are continuous on both virtual
>> and physical address space, so such page fragment converting should be
>> safe until we use slab allocator to free them.
>>
>
> Its not safe at all. Good luck with coping with SLAB, SLUB, SLOB, and
> various debugging facilities on top of them.
>
The slab class API semantic should not change among them. the debugging
facilities should only add or modify metadata around user bytes too.
However, I also decided giving up use kmalloced() objects since it is
hard to free them safely them without some extra efforts after doing
page fragmentation on them.
I think that adding skb->frag_head indeed is a better choice, this means
I have to rework some NIC drivers :(
>> I ask this question since I am working on a patch to try to directly
>> forward the data from rx queue of a socket to tx queue of another
>> socket. We noticed that the splice itself still has visible costs when
>> forwarding small messages, and hope such direct forwarding optimization
>> can improve this, this idea comes from TCP friends.
>
> If not using splice, you directly transfert one skb coming from one
> side, to the other side, so you dont care skb->head being a frag or not.
>
> If messages are small, there is probably no hope trying to coalesce them
> (or else fixing the application would be much easier)
>
This patch is hoped that can work well for big messages too, so I
selected moving page fragment, and I think this should be easier a bit
because I can directly reuse tcp_sendpage() interface or just need a bit
of changes on it :)
If it can work well, I will send it out.
Thans very much for your time, :)
Yu
>
>
>
next prev parent reply other threads:[~2012-11-09 2:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 10:33 [PATCH 1/4 net-next] net: allow skb->head to be a page fragment Eric Dumazet
2012-04-28 0:27 ` Alexander Duyck
2012-04-28 6:30 ` Eric Dumazet
2012-04-28 7:16 ` Eric Dumazet
2012-04-28 8:27 ` Alexander Duyck
2012-04-28 9:22 ` David Miller
2012-05-01 1:48 ` David Miller
2012-11-07 8:20 ` Li Yu
2012-11-07 8:35 ` Li Yu
2012-11-07 11:04 ` Eric Dumazet
2012-11-08 7:46 ` Li Yu
2012-11-08 13:30 ` Eric Dumazet
2012-11-09 2:31 ` Li Yu [this message]
2012-11-09 2:37 ` Eric Dumazet
2012-11-09 2:50 ` Li Yu
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=509C6AEF.4020300@gmail.com \
--to=raise.sail@gmail$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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