Re: [PATCH libnetfilter_queue v4] src: eliminate packet copy when constructing struct pktbuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pablo,

On Mon, Mar 28, 2022 at 01:48:21PM +1100, Duncan Roe wrote:
> To avoid a copy, the new code takes advantage of the fact that the netfilter
> netlink queue never returns multipart messages.
> This means that the buffer space following that callback data is available for
> packet expansion when mangling.
>
> nfq_cb_run() is a new nfq-specific callback runqueue for netlink messages.
> The principal function of nfq_cb_run() is to pass to the called function what is
> the length of free space after the packet.
>
> pktb_setup is a new function to initialise a new struct pkt_buff.
>
> pktb_head_size() is a new function to return the amount of memory to reserve
> for a new struct pkt_buff.
>
> nfq_cb_t is a new typedef for the function called by nfq_cb_run()
> [c.f. mnl_cb_t / mnl_cb_run].
>
> examples/nf-queue.c is updated to demonstrate the new API.
>
> Signed-off-by: Duncan Roe <duncan_roe@xxxxxxxxxxxxxxx>
> ---
> v4:
> New functions have man pages / html doc
> struct pkt_buff remains opaque
> pktb_populate renamed pktb_setup
[...]

This patch locks in that the netfilter queue will never batch multiple packets:
is that a problem?

If you like I could send a v5 documenting that programs that hold on to multiple
packets should [continue to] use mnl_cb_run / pktb_alloc / pktb_free.

Re documentation: of course I would like to rework it to replace "deprecated"
with e.g. "old interface". There would be a section comparing the old and new
interfaces. I would rather not have to write in that section that the old
interface is faster (but can't mangle).

If you apply this patch, the old interface would no longer be faster.

Cheers ... Duncan.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux