On Wed, Mar 23, 2016 at 01:13:06AM +0000, Daniele Di Proietto wrote: > > On 22/03/2016 17:57, "Ben Pfaff" <b...@ovn.org> wrote: > > >On Mon, Mar 14, 2016 at 06:18:17PM +0300, Ilya Maximets wrote: > >> This is unused functionality and it will harm to > >> multiqueue implementation. > >> > >> Signed-off-by: Ilya Maximets <i.maxim...@samsung.com> > > > >This change doesn't make any sense to me. An equivalent change to the > >Linux kernel would mean that if two copies of "tcpdump -i eth0" were > >running then only one of them would get any packets. > > I independently decided to make a very similar code change with the > same semantics to netdev-dummy, so maybe there's something I don't > understand as well :-) > > netdev-dummy is like a physical NIC, the wire is a stream object > (or the netdev-dummy/receive appctl, but only in one direction). > > When a multi queue NIC receives a packet from the wire it should > put it in just one of its rings, right?
I don't understand the confusion. Suppose I call netdev_rxq_open() on a netdev that's backed by netdev-linux, say for eth0. That calls into netdev_linux_rxq_construct(), which opens a Linux AF_PACKET socket. From then on, I can call netdev_rxq_recv() on the netdev_rxq that I got (call it rxq0), and get a copy of each packet received on eth0. Suppose I call netdev_rxq_open() on the same netdev again. I get an independent netdev_rxq socket for eth0 (call it rxq1). I can call netdev_rxq_recv() on both rxq0 and rxq1 and I'll get two copies of the same stream of packets. netdev-dummy is implementing the same thing. struct netdev_dummy has a list of open "netdev_rxq"s as its member named 'rxes'. Each of those gets a copy of all the received packets. So...am I missing something? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
