Hi Evgeniy,

quoted text
> There are several possibilities:
> * update destructor with your own data and put old one behind the data
>        in skb
> * update destructor, but put your own data into some storage which can
>        be accessed from your callback, storage entry may contain
>        whatever data you want and of course old destructor
> * put your data into socket pointer (there still may be issues with
>        destructor)
> * if you fully own the skb, reuse whatever members there you like
>        (except those which may be used by lower layer)
> * find why do you need to have callback at destruction time and
>        eliminate this problem.
>        Btw, netchannels do this way, since they are very similar to
>        packet socket, but compared to your approach they have a copy.
>
Thanks a lot for this list :)
So for example, is using of skb->mark to store a buffer index a good solution ?
Or do you prefer another solution?

quoted text
> At the first place I do not understand, why do you want to change the
> skb, since you can mmap whatever area you need and provide those pages
> into skb, which at free time will drop the reference counter. Skb lives
> in socket queue, so until it is empty you can sleep not allowing mapped
> buffer to shrink.
We need to get the tpacket_hdr associated to data in skb in order to
inform user that buffer is now available (This is done through status
field, which is not sent over the network). What do you mean with
"provide those pages", through frags? If yes, is it ok when frags are
linearized?

Best regards,
Johann


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