Hi Ilya, I see, thanks. So we'll need to take this into account. Cheers, Vincenzo
2018-02-09 12:30 GMT+01:00 Ilya Maximets <[email protected]>: > On 08.02.2018 17:21, Vincenzo Maffione wrote: > > Hi Ilya, > > > >> Hi, > > > > > > Hi, Alessandro. > > > > > > > > My name is Alessandro Rosetti, and I'm currently adding netmap > support to > > > ovs, following an approach similar to DPDK. > > > > Good to know that someone started to work on this. IMHO, it's a good > idea. > > I also wanted to try to implement this someday, but had no much time. > > > > > > > > I've created a new netdev: netdev_netmap that uses the pmd > infrastructure. > > > The prototype I have seems to work fine (I still need to tune > performance, > > > test optional features, and test more complex topologies.) > > > > Cool. Looking forward for your RFC patch-set. > > > > > > > > I have a question about the lifetime of dp_packets. > > > Is there any guarantee that the dp_packets allocated in a receive > callback > > > (e.g. netdev_netmap_rxq_recv) are consumed by OVS (e.g. dropped, > cloned, or > > > sent to other ports) **before** a subsequent call to the receive > callback > > > (on the same port)? > > > Or is it possible for dp_packets to be stored somewhere (e.g. in > an OVS > > > internal queue) and live across subsequent invocations of the > receive > > > callback that allocated them? > > > > I think that there was never such a guarantee, but recent changes in > userspace > > datapath completely ruined this assumption. I mean output packet > batching support. > > > > Please refer the following commits for details: > > 009e003 2017-12-14 | dpif-netdev: Output packet batching. > > c71ea3c 2018-01-15 | dpif-netdev: Time based output batching. > > 00adb8d 2018-01-15 | docs: Describe output packet batching in DPDK > guide. > > > > > > Thanks a lot for for the quick reply. So we will add a dp_packet > allocator for netmap. > > Is there is any guarantee that a dp_packet allocated by a PMD thread > will be deallocated > > by the same thread and only the same thread? At first glance it seems > this is the case... > > Hi Vincenzo, > > I would prefer that you do not make such assumptions. Even if it works now, > netdev abstraction layer doesn't guarantee that. It states that > 'rxq_recv()' > function of netdev-provider "stores pointers to up to NETDEV_MAX_BURST > dp_packets into the array, transferring ownership of the packets to the > caller". > This means that caller is able to do anything with received dp_packets > including > but not limited to queueing or transferring to another thread. > > > > > Thanks, > > Vincenzo > > > > > > > > > > > > I need to know if this is the case to check that my current > prototype is > > > safe. > > > I use per-port pre-allocation of dp_packets, for maximum > performance. I've > > > seen that DPDK uses its internal allocator to allocate and > deallocate > > > dp_packets, but netmap does not expose one. > > > Each packet received with netmap is created as a new type > dp_packet: > > > DPBUF_NETMAP. The data points to a netmap buffer (preallocated by > the > > > kernel). > > > When I receive data (netdev_netmap_rxq_recv) I reuse the > dp_packets, > > > updating the internal pointer and a couple of additional > informations > > > stored inside the dp_packet. > > > When I have to send data I use zero copy if dp_packet is > DPBUF_NETMAP and > > > copy if it's not. > > > > > > Thanks for the help! > > > Alessandro. > > > > > > > > > > > > > > -- > > Vincenzo Maffione > -- Vincenzo Maffione _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
