> > > > Also, given these required calls to get_vid (which afaik requires
> > > > some slow memory fencing) wouldn't that argue for the original
> > > approach where the rxq len is returned from rxq_recv(). As the call to
> > > rxq_length()  would be made once per batch once the queue is not being
> > drained rxq_recv() the overhead could be significant.
> > >
> > > I'm not sure (I hope that Jan tested the performance of this version),
> > > but I feel that 'rte_vhost_rx_queue_count()' is more heavy operation.
> >
> > I have not done any performance tests yet with the new
> > netdev_rxq_length() call after adding the vid and other checks. The actual
> > 'rte_vhost_rx_queue_count()' is very lightweight. So if the memory fencing
> > for get_vid() is expensive it might mean a hit. (Note: The
> > rte_eth_queue_count() functions for physical ixgbe queues was much more
> > costly).
> >
> > Thinking about it, I would tend to agree with Billy that it seems simpler 
> > as well
> > as more accurate and efficient to let the caller provide an optional output
> > parameter "uint32_t *rxq_len" in rqx_recv() if they are interested in the
> > queue fill level and retrieve both in one atomic operation, so that we avoid
> > the duplicate vid checks.
> [[BO'M]] I like the idea of supplying the pointer which makes it optional and 
> so gets around other issues we discussed - such as a client
> may only be interested in rxq len for certain netdev types or may know a 
> priori that it's an expensive operation for other netdev types.

Thanks. I am preparing v8 with this change. The optional output parameter will 
return the remaining
queue length after receiving the packet batch. That seems a meaningful metric 
for the rxq_recv() API
as it would also allow the caller to decide whether or not to continue polling 
(e.g. in the context
of the priority polling scheme).

BR, Jan

> >
> > Can we agree on that?
> >
> > BR, Jan

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to