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

[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 at intel.com
> <mailto:ferruh.yigit at 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 at intel.com <mailto:ferruh.yigit at intel.com>
>     > <mailto:ferruh.yigit at intel.com <mailto:ferruh.yigit at 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..

Thanks,
ferruh