From: "Eric Barton" <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 13:23:10 +0100
> > Even if your two pointers addition (16 bytes on x86_64)
> > doesnt cross a 64bytes
> > line (I didn't checked), they are going to be set to NULL
> > each time a skbuff
> > is allocated , and checked against NULL
On Tue, Oct 17, 2006 at 01:50:04PM +0100, Eric Barton ([EMAIL PROTECTED]) wrote:
> Evgeniy,
>
> > You can use existing skb destructor and appropriate reference
> > counter is already there. In your own destructor you need to
> > call old one of course, and it's type can be determined from
> > the
Evgeniy,
> You can use existing skb destructor and appropriate reference
> counter is already there. In your own destructor you need to
> call old one of course, and it's type can be determined from
> the analysis of the headers and skb itself (there are not so
> much destructor's types actually).
> In addition to that I'm pretty sure I remember that some clusterfs
> person already posted these patches a while ago and got ripped apart
> in the same way.
Yes - unfortunately I didn't submit my patch personally. And I've
rewritten it since to to avoid the obvious criticisms. This time
around
> > Also, (please correct me if I'm wrong) I didn't
> > think this would push the allocation over to the next entry in
> > 'malloc_sizes'.
>
> Well, skbuff heads are allocated from dedicated kmem_cache
> (skbuff_fclone_cache & skbuff_head_cache), and these caches are not
> constrained by the siz
On Tue, Oct 17, 2006 at 01:53:02AM +0100, Eric Barton ([EMAIL PROTECTED]) wrote:
> > And these days we're trying to figure
> > out how to eliminate skbuff and skb_shared_info struct members
> > whereas you're adding 16-bytes of space on 64-bit platforms.
>
> Do you think the general concept of a z
On Tuesday 17 October 2006 02:53, Eric Barton wrote:
> If so, do you have any ideas about how to do it more economically? It's 2
> pointers rather than 1 to avoid forcing an unnecessary packet boundary
> between successive zero-copy sends. But I guess that might not be hugely
> significant since
David,
> Also, the correct mailing list to get to the networking developers
> is [EMAIL PROTECTED] "linux-net" is for users.
Noted.
> Finally, I very much doubt you have much chance getting this
> change in, the infrastructure is implemented in a very ad-hoc
> fashion and it takes into consider
This patch has been used with the lustre cluster file system (www.lustre.org)
to give notification when page buffers used to send bulk data via TCP/IP may be
overwritten. It implements...
a) A general-purpose callback to inform higher-level protocols when a
zero-copy send of a set of page
This patch has been used with the lustre cluster file system (www.lustre.org)
to give notification when page buffers used to send bulk data via TCP/IP may be
overwritten. It implements...
a) A general-purpose callback to inform higher-level protocols when a
zero-copy send of a set of page
10 matches
Mail list logo
