All of lore.kernel.org
 help / color / mirror / Atom feed
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

>
>
>

  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.com \
    --cc=eric.dumazet@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.