On Thu, Jan 20, 2022 at 01:40:09PM +0100, Pablo Neira Ayuso wrote: > On Thu, Jan 20, 2022 at 01:04:58PM +0100, Florian Westphal wrote: > > Duncan Roe <duncan_roe@xxxxxxxxxxxxxxx> wrote: > > > On Tue, Jan 18, 2022 at 02:11:43AM +0100, Pablo Neira Ayuso wrote: > > > > > > > > This patch have a number of showstoppers such as exposing structure > > > > layout on the header files. > > > > > > > That's only in patch 5. You could apply 1-4. There are actually no other > > > showstoppers, right? > > > > Regarding patch 5, I think its ok except the pkt_buff layout freeze. > > > > From a quick glance, there is no assumption that the data area resides > > after the pktbuff head, so it should be possible to keep pkt_buff > > private, allocate an empty packet and then associate a new buffer with > > it. > > Or allocate pktbuff offline and recycle it (re-setup) on new packets > coming from the kernel, it does not need to be allocated in the > stack and exposing the layout is also therefore not requireed. I put it on the stack to get thread locality w/out the (admittedly small) overhead of using thread_local. We could have a pktbuff_size() to dimension it and keep the struct opaque. It's 48 bytes (64 bit) so I thought it was OK on the stack but you could malloc() it and only have a pointer (again on the stack for thread locality). Cheers ... Duncan.
