qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] net: add initial support for AF_XDP network backend


From: Ilya Maximets
Subject: Re: [PATCH] net: add initial support for AF_XDP network backend
Date: Wed, 28 Jun 2023 01:10:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

On 6/27/23 10:56, Stefan Hajnoczi wrote:
> Can multiple VMs share a host netdev by filtering incoming traffic
> based on each VM's MAC address and directing it to the appropriate
> XSK? If yes, then I think AF_XDP is interesting when SR-IOV or similar
> hardware features are not available.

Good point.  Thanks!

Yes, they can.  Traffic can be re-directed via 'ethtool -N' similarly
to an example in the patch.  Or, potentially, via custom XDP program.
Then different QEMU instances may use different start-queue arguments
and use their own range of queues this way.

> 
> The idea of an AF_XDP passthrough device seems interesting because it
> would minimize the overhead and avoid some of the existing software
> limitations (mostly in QEMU's networking subsystem) that you
> described. I don't know whether the AF_XDP API is suitable or can be
> extended to build a hardware emulation interface, but it seems
> plausible. When Stefano Garzarella played with io_uring passthrough
> into the guest, one of the issues was guest memory translation (since
> the guest doesn't use host userspace virtual addresses). I guess
> AF_XDP would need an API for adding/removing memory translations or
> operate in a mode where addresses are relative offsets from the start
> of the umem regions

Actually, addresses in AF_XDP rings are already offsets from the
start of the umem region.  For example, xsk_umem__get_data is
implemented as &((char *)umem_area)[addr]; inside libxdp.  So, that
should not be an issue.

> (but this may be impractical if it limits where
> the guest can allocate packet payload buffers).

Yeah, we will either need to:

a. register the whole guest memory as umem and offset buffer pointers
   in the guest driver by the start of guest physical memory.

   (I'm not familiar much with QEMU memory subsystem.  Is guest physical
    memory always start at 0? I know that it's not always true for the
    real hardware.)

b. or require the guest driver to allocate a chunk of aligned contiguous
   memory and copy all the packets there on Tx.  And populate the Fill
   ring only with buffers from that area.  Assuming guest pages align
   with the host pages.  Again, a single copy might not be that bad,
   but it's hard to tell what the actual impact will be without testing.

> 
> Whether you pursue the passthrough approach or not, making -netdev
> af-xdp work in an environment where QEMU runs unprivileged seems like
> the most important practical issue to solve.

Yes, working on it.  Doesn't seem to be hard to do, but I need to test.

Best regards, Ilya Maximets.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]