On Mon, Jan 13, 2020 at 07:51:50PM +0100, Pablo Neira Ayuso wrote: > On Fri, Jan 10, 2020 at 01:27:57PM +1100, Duncan Roe wrote: > > On Wed, Jan 08, 2020 at 11:53:23PM +0100, Pablo Neira Ayuso wrote: > > > On Mon, Jan 06, 2020 at 02:17:13PM +1100, Duncan Roe wrote: > > > > This patch offers a faster alternative / replacement function to pktb_alloc(). > > > > > > > > pktb_make() is a copy of the first part of pktb_alloc() modified to use a > > > > supplied buffer rather than calloc() one. It then calls the second part of > > > > pktb_alloc() which is modified to be a static function. > > > > > > > > Can't think of a use case where one would choose to use pktb_alloc over > > > > pktb_make. > > > > In a furure documentation update, might relegate pktb_alloc and pktb_free to > > > > "other functions". > > > > > > This is very useful. > > > > > > Would you explore something looking similar to what I'm attaching? > > > > > > Warning: Compile tested only :-) > > > > > > Thanks. > > [...] > > > > Ok, so this is another approach to reducing CPU time: avoid memcpy of data. > > > > That's great if you're not mangling content. > > > > But if you are mangling, beware. pktb now has pointers into the buffer you used > > for receiving from Netlink so you must use a different buffer when sending. > > Probably we can store a flag in the pkt_buff structure to say "this > buffer is now ours" so mangling can just trigger a clone via malloc() > + memcpy() only for that path. Not for pktb_make: we never call pktb_free. > > Or you can just document this, although handling this case for the > library would be make it easier to user for users. ATM I have to document that you must use separate Rx & Tx netlink buffers if mangling at all, because otherwise you may get overlapping data moves or worse. So I'm inclined to document about no length increase. But ... There *is* room at the end of the buffer, as long as the received Netlink message didn't fill it. We just need some way to know about it - maybe extra args to the _data functions and maybe as well more _data helper functions to keep it easy to use. As well, I've been toying with the idea of not copying data out of the Rx buffer at all, but rather building the verdict message around it. I have in mind a user-space-only header to go at the front of the buffer, to be created before receiving into it. There's still the copies out from and back into kernel space - guess we're stuck with those. Cheers ... Duncan. > > Thanks.
