netdev - Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1352381449.19779.13.camel@edumazet-glaptop>
Date:	Thu, 08 Nov 2012 05:30:49 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Li Yu <raise.sail@...il.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment

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.

> 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)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html