On 08.02.2018 17:21, Vincenzo Maffione wrote:
> Hi Ilya,
> 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
> > The prototype I have seems to work fine (I still need to tune
> > 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
> > (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
> > (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
> datapath completely ruined this assumption. I mean output packet batching
> 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
> by the same thread and only the same thread? At first glance it seems this is
> the case...
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.
> > 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.
> > 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
> > copy if it's not.
> > Thanks for the help!
> > Alessandro.
> Vincenzo Maffione
dev mailing list