On Mon, Jul 8, 2019 at 4:14 PM Ilya Maximets <[email protected]> wrote: > > On 07.07.2019 19:13, David Marchand wrote: > > Add a statistic to help diagnose contention on the vhost txqs. > > This is usually seen as dropped packets on the physical ports for rates > > that are usually handled fine by OVS. > > > > Signed-off-by: David Marchand <[email protected]> > > --- > > This patch applies on top of Kevin "vhost-retry" series [1]. > > > > 1: https://patchwork.ozlabs.org/project/openvswitch/list/?submitter=70482 > > --- > > Documentation/topics/dpdk/vhost-user.rst | 25 +++++++++++++++++++++++++ > > lib/netdev-dpdk.c | 20 ++++++++++++++++++-- > > 2 files changed, 43 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/topics/dpdk/vhost-user.rst > > b/Documentation/topics/dpdk/vhost-user.rst > > index 724aa62..e276b21 100644 > > --- a/Documentation/topics/dpdk/vhost-user.rst > > +++ b/Documentation/topics/dpdk/vhost-user.rst > > @@ -553,6 +553,31 @@ shown with:: > > > > $ ovs-vsctl get Interface dpdkvhostclient0 statistics:tx_retries > > > > +vhost tx contention > > +------------------- > > + > > +Contrary to physical ports where the number of Transmit queues is decided > > at > > +the configuration of the port and does not change once set up, the number > > of > > +Transmit queues for a vhost-user or vhost-user-client interface is > > negociated > > +with the guest when its driver enables a virtio interface and OVS has no > > +control over it. > > + > > +Each PMD threads needs a Transmit queue to send packet on such a port. > > +To accomodate with the cases where the number of PMD threads differs from > > the > > +number of Transmit queues enabled by a Virtual Machine, the Transmit > > queues are > > +distributed among the PMD threads and their accesses are protected by a > > +spinlock. > > + > > +When contention occurs (because two PMD threads are mapped to the same > > Transmit > > +queue), it can be hard to understand this phenomenon. > > +It usually will be seen as OVS taking more cycles to handle the packet and > > can > > +be seen as packets getting dropped on the receive side (rx_dropped > > statistic > > +on the physical ports). > > + > > +A statistic for the port is available to catch those cases:: > > + > > + ovs-vsctl get Interface dpdkvhostclient0 statistics:tx_contentions >
Sorry, I have been a bit busy with 19.08. Back on this topic. > > I'm concerned about this statistics. 'tx_retries' had a slight connection > with the networking and the end user is able to understand what it means, > but this one is fully abstracted from the network and requires the deep > knowledge of the current netdev-dpdk implementation to understand what does > it mean. > > I see 2 options for counters like this: > > 1. coverage counter. > 2. PMD perf. stats. > > The first one is the definitely correct place for such statistics, but we'll > loose some information like the port where this happened. > > The second one seems suitable too, but it's hard to expose information to > the upper layer from netdev (see the awful vhost qfill). This is, however, > could be solved by re-implementing the dpif-netdev-perf with the 'coverage > counters' like approach, how I suggested previously while discussing the > original 'dpif-netdev-perf' patch-set. > > So, for now, I'm voting for a simple coverage counter. I went with your suggestion for the coverage counter. It gives an indication that a contention is happening which is what I wanted to catch first. Not entirely sure how to rework the dpif-netdev-perf, but I can have a look at this if you have ideas/pointers. Thanks. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
