On Mon, Sep 23, 2019 at 6:01 AM Eelco Chaudron <echaudro@xxxxxxxxxx> wrote: > > > > On 23 Sep 2019, at 11:00, Július Milan wrote: > > > Many Thanks Magnus > > > >>> I have next 2 questions: > >>> > >>> 1] When I use xsk_ring_prod__reserve and successive > >>> xsk_ring_prod__submit. Is it correct to submit also less than I > >>> reserved? > >>> In some cases I can't exactly determine how much to reserve in > >>> advance, since vpp buffers have different size than xdp frames. > >> > >> Let me see so I understand this correctly. Ponder you reserve 10 > >> slots and later submit 4. This means you have reserved 6 more than > >> you need. > >> Do you want to "unreserve" these and give them back to the ring? This > >> is not supported by the interface today. Another way of solving this > >> (if this is your problem and I am understanding it correctly, that > >> is) is that you in the next iteration only reserve 10 - 6 = 4 slots > >> because you already have 6 slots available from the last iteration. > >> You could still submit 10 after this. But adding something like an > >> unreserve option would be easy as long as we made sure it only > >> affected local ring state. The global state seen in the shared > >> variables between user space and kernel would not be touched, as this > >> would affect performance negatively. Please let me know what you > >> think. > >> > > Yes, You understand it correctly, I implemented it the way you > > suggested, i.e. by marking index and count of reserved slots (not > > committed yet, but works well), thanks again. > > > >>> 2] Can I use hugepage backed memory for umem? If not, is it planned > >>> for future? > >>> Yet it does copy pakets from rx rings to vpp buffers, but > >>> speculating about straight zerocopy way. > >> > >> Yes you can use huge pages today, but the internal AF_XDP code has > >> not been optimized to use huge pages, so you will not get the full > >> benefit from them today. Kevin Laatz, added to this mail, is working > >> on optimizing the AF_XDP code for huge pages. If you want to know > >> more or have some requirements, do not hesitate to contact him. > >> > > Kevin will the API for using hugepages change while optimization > > process significantly or can I already start to rewrite my vpp driver > > to use hugepages backed memory? > > Also please let me know, when you consider AF_XDP code optimized to > > use huge pages. > > > > William, if I may ask next question. > > Does OVS implementation of af_xdp driver copy paket data from af_xdp > > mmaped ring buffers into OVS "buffers" (some structure to represent > > the packet in OVS) or is it zerocopy > > in this manner, i.e. OVS "buffers" mempool is directly mmaped as ring > > and so no copy on RX is needed. Since in 2nd case it would be very > > valuable for me as inspiration. > > Currently, OVS uses the mmaped memory directly, however on egress, it is > copying the memory to the egress interface it’s mmaped memory. > Currently, OVS uses an AF_XDP memory pool per interface, so a further > optimization could be to use a global memory pool so this extra copy is > not needed. > That's right, thanks Eelco! For OVS, it is zerocopy in the RX. William
|