[dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue ops

Varghese, Vipin vipin.varghese at intel.com
Thu Dec 6 15:16:17 CET 2018


snipped
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Varghese, Vipin
> > Sent: Thursday, December 6, 2018 5:27 AM
> > To: Lu, Wenzhuo <wenzhuo.lu at intel.com>; dev at dpdk.org
> > Cc: Yang, Qiming <qiming.yang at intel.com>; Li, Xiaoyun
> > <xiaoyun.li at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> > Subject: Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and
> > queue ops
> >
> > Hi Wenzhuo,
> >
> > Please find my updates below
> >
> > snipped
> > > > > +	if (!vsi->rss_key)
> > > > > +		vsi->rss_key = rte_zmalloc("rss_key",
> > > > > +					   vsi->rss_key_size, 0);
> > > > > +	if (!vsi->rss_lut)
> > > > > +		vsi->rss_lut = rte_zmalloc("rss_lut",
> > > > > +					   vsi->rss_lut_size, 0);
> > > >
> > > > 2 suggestions
> > > > 1. should the name be macro?
> > > Sorry, which name?
> > Would you like to convert and use as?
> > #define ICE_RSS_KEY "rss_key"
> > #define ICE_RSS_LUT "rss_lut"
> >
> > And replace ' rte_zmalloc("rss_key",' as ' rte_zmalloc(ICE_RSS_KEY,'
> > >
> > > > 2. if there are multiple 810 NIC under DPDK, should not each rss
> > > > be different like "rss_key-%u" where it is port number?
> > > Sorry, don't understand the question.
> > Let assume we have 2 ICE_DSI NIC on PCIe bus. Then crating '
> rte_zmalloc("rss_key",' for port 1 will fail since malloc region "rss_key"
> > already exist for port 0
> 
> It wouldn't.
> rte_malloc() simply ignores name argument.
> You can even put NULL here.
> As I remember, Anatoly suggested to remove it completely in future.
> Konstantin
Ohh, this I was not aware. Then the suggestion from my end would be to pass 'NULL'. Wenzhuo you can ignore the MACRO and safe thing is passing NULL. 

> 
> >
> > >
> > > >
> > > > Snipped
> > > >
> > > > > +
> > > > > +static int
> > > > > +ice_dev_start(struct rte_eth_dev *dev) {
> > > > > +	struct rte_eth_dev_data *data = dev->data;
> > > > > +	struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data-
> > > > > >dev_private);
> > > > > +	struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data-
> > > > >dev_private);
> > > > > +	uint16_t nb_rxq = 0;
> > > > > +	uint16_t nb_txq, i;
> > > > > +	int ret;
> > > > > +
> > > > > +	ICE_PROC_SECONDARY_CHECK;
> > > >
> > > > Device start is not supported, but how is this differentiated from
> > > > primary configured device vs secondary configured device.
> > > >
> > > > Ie: primary uses black list '-b BB:DD:F' while secondary uses '-w
> > > > BB:DD:F'. In this case since we are checking process type this
> > > > will return without
> > > start?
> > Two updates with respect to your comment, 1. tool and application like
> > dpdk-procinfo will no longer be able pull data since you are asking to black
> list.
> > 2. If there are functions which needs to shared, like primary using rx-0 and tx-
> 0 then secondary rx-1 and tx-1 how to make this work?
> >
> > snipped



More information about the dev mailing list