Re: [dpdk-dev] [PATCH v2 20/25] bnxt: add support to get and clear VF specific stats

[Thomas Monjalon <thomas@monjalon.net>]

31/05/2017 16:46, Ferruh Yigit:
> On 5/31/2017 3:27 PM, Ajit Khaparde wrote:
> > On Wed, May 31, 2017 at 4:57 AM, Ferruh Yigit <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>>wrote:
> > 
> >     On 5/31/2017 3:12 AM, Ajit Khaparde wrote:
> >     >
> >     > On Mon, May 29, 2017 at 12:43 PM, Ferruh Yigit <ferruh.yigit@intel.com <mailto:ferruh.yigit@intel.com>
> >     > <mailto:ferruh.yigit@intel.com <mailto:ferruh.yigit@intel.com>>>
> >     wrote:
> >     >
> >     >     > +int rte_pmd_bnxt_get_tx_drop_count(uint8_t port, uint64_t
> >     *count)
> >     >     > +{
> >     >     > +     struct rte_eth_dev *dev;
> >     >     > +     struct rte_eth_dev_info dev_info;
> >     >     > +     struct bnxt *bp;
> >     >     > +
> >     >     > +     dev = &rte_eth_devices[port];
> >     >     > +     rte_eth_dev_info_get(port, &dev_info);
> >     >     > +     bp = (struct bnxt *)dev->data->dev_private;
> >     >     > +
> >     >     > +     return bnxt_hwrm_func_qstats_tx_drop(bp, 0xffff, count);
> >     >     > +}
> >     >
> >     >     This function is not to get VF stats from PF. As far as I can
> >     see this
> >     >     just gets queue stats, does this really needs to be PMD
> >     specific API,
> >     >     isn't this something generic?
> >     >
> >     >
> >     > ​Yes. That is right. It returns a count of number of packets which
> >     were
> >     > not transmitted
> >     > because it did not pass the MAC/VLAN spoof check.
> >     > It does not
> >     > necessarily mean "failure to transmit" and so I don't think it is
> >     right
> >     > to map it to oerrors.
> >     > So in the current form I don't see a way to make a generic
> >     function out
> >     > of it.​
> > 
> >     I see, this is implemented because there is no place in basic stats to
> >     put tx_drop_pkts.
> > 
> >     Can xstats be used to get this value? Can new .xstats_get_by_id help
> >     here?
> > 
> > ​May be we could. Do we have time for that?​
> 
> Agreed that this may require effort, but I believe we should not use PMD
> specific APIs as much as possible, and stick to ethdev abstraction layer.
> 
> PMD specific API kills the portability, and only should be used to
> benefit from features that are available only for that PMD.
> 
> This was my concern to start implementing more thing in PMD layer, like
> getting tx_drop stats..

Yes I agree the specific statistics should be added in xstats.