Re: some questions about TPACKET3

[Mario Rugiero via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Mario Rugiero <mrugiero () gmail com>
>
> Date: Sun, 28 Jun 2020 18:16:50 -0300
>
> El dom., 28 jun. 2020 a las 18:02, Michael Richardson
> (<mcr () sandelman ca>) escribió:
> > Mario Rugiero via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
> >     >> For a contract, I am trying to improve the write performance by using
> >     >> async I/O.  {I also need to associate requests and responses, which makes the
> >     >> ordering of operations non-sequential}
> >     >> I therefore do not want to give the blocks back to the kernel until the
> >     >> write has concluded, and for this I'm working on a variation of
> >     >> linux_mmap_v3(), which will callback with groups of packets, through
> >     >> a pipeline of "processors", each of which may steal the packet, and
> >     >> then return it later.
> >     >>
> >     >> I am realizing that I have to keep track of the blocks, not just the
> >     >> packets.  I guess my original conceptual thinking was too heavily
> >     >> influenced by V2, and I was thinking that V3 had changed things by
> >     >> splitting the hdr from the packet, putting the constant-sized hdrs
> >     >> into a fixed sized ring, while the packet content was allocated
> >     >> as needed.
> >     >> I see that I am mistaken, but I'd sure love confirmation.
> >
> >     > I believe you may be thinking of AF_XDP. As you probably know, libpcap doesn't
> >     > have support for it (yet), but I don't think you'll have trouble using
> >     > it directly.
> >
> > Ah!
> > That explains some of my confusion.  That's interesting to understand though.
> > Please confirm that your explanation below is about AF_XDP, not V3 :-)
> Yes, all below is AF_XDP :)
>
> > Can you confirm that V3 works the way I think?
> > We want to support AF_XDP eventually.
> > Maybe we should support V2 for legacy and XDP for future.
> > Hmm.
> If you can pay the overhead, maybe V3 with some metadata for reference
> counting could do the trick. You would decrement the counter just before sending
> the matching packet, and release the block when it hits 0. What do you think?
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh networks [
> > ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> > ]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on rails    [
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers