On Fri, 23 Aug 2019 06:00:45 +0000, Saeed Mahameed wrote: > On Thu, 2019-08-22 at 18:33 -0700, Jakub Kicinski wrote: > > On Thu, 22 Aug 2019 23:35:52 +0000, Saeed Mahameed wrote: > > > From: Moshe Shemesh <mo...@mellanox.com> > > > > > > Added the following packets drop counter: > > > Device out of buffer - counts packets which were dropped due to > > > full > > > device internal receive queue. > > > This counter will be shown on ethtool as a new counter called > > > dev_out_of_buffer. > > > The counter is read from FW by command QUERY_VNIC_ENV. > > > > > > Signed-off-by: Moshe Shemesh <mo...@mellanox.com> > > > Signed-off-by: Saeed Mahameed <sae...@mellanox.com> > > > > Sounds like rx_fifo_errors, no? Doesn't rx_fifo_errors count RX > > overruns? > > No, that is port buffer you are looking for and we got that fully > covered in mlx5. this is different. > > This new counter is deep into the HW data path pipeline and it covers > very rare and complex scenarios that got only recently introduced with > swichdev mode and "some" lately added tunnels offloads that are routed > between VFs/PFs. > > Normally the HW is lossless once the packet passes port buffers into > the data plane pipeline, let's call that "fast lane", BUT for sriov > configurations with switchdev mode enabled and some special hand > crafted tc tunnel offloads that requires hairpin between VFs/PFs, the > hw might decide to send some traffic to a "service lane" which is still > fast path but unlike the "fast lane" it handles traffic through "HW > internal" receive and send queues (just like we do with hairpin) that > might drop packets. the whole thing is transparent to driver and it is > HW implementation specific.
I see thanks for the explanation and sorry for the delayed response. Would it perhaps make sense to indicate the hairpin in the name? dev_out_of_buffer is quite a generic name, and there seems to be no doc, nor does the commit message explains it as well as you have..
