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 <i.maxim...@samsung.com>:

> 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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to