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

Reply via email to