snipped
> > -----Original Message-----
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Varghese, Vipin
> > Sent: Thursday, December 6, 2018 5:27 AM
> > To: Lu, Wenzhuo <wenzhuo...@intel.com>; dev@dpdk.org
> > Cc: Yang, Qiming <qiming.y...@intel.com>; Li, Xiaoyun
> > <xiaoyun...@intel.com>; Wu, Jingjing <jingjing...@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
