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
