[dpdk-dev] [PATCH v2 20/25] bnxt: add support to get and clear VF specific stats
Ajit Khaparde
ajit.khaparde at broadcom.com
Wed May 31 20:41:59 CEST 2017
On Wed, May 31, 2017 at 11:15 AM, Thomas Monjalon <thomas at monjalon.net>
wrote:
> 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 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..
>
> Yes I agree the specific statistics should be added in xstats.
>
And I am already working on that. Thanks
More information about the dev
mailing list