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
, and checked against NULL each time a skbuff is
> destroyed.
Indeed. Do you think that's significant?
Cheers,
Eric
---
|Eric BartonBarton Software |
|9 York Gardens Tel:
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
