Re: [PATCH net-next v1 3/3] hinic: add support to query function table

[Jakub Kicinski]

On Fri, 28 Aug 2020 11:16:22 +0800 luobin (L) wrote:
> On 2020/8/28 3:44, Jakub Kicinski wrote:
> > On Thu, 27 Aug 2020 19:13:21 +0800 Luo bin wrote:  
> >> +	switch (idx) {
> >> +	case VALID:
> >> +		return funcfg_table_elem->dw0.bs.valid;
> >> +	case RX_MODE:
> >> +		return funcfg_table_elem->dw0.bs.nic_rx_mode;
> >> +	case MTU:
> >> +		return funcfg_table_elem->dw1.bs.mtu;
> >> +	case VLAN_MODE:
> >> +		return funcfg_table_elem->dw1.bs.vlan_mode;
> >> +	case VLAN_ID:
> >> +		return funcfg_table_elem->dw1.bs.vlan_id;
> >> +	case RQ_DEPTH:
> >> +		return funcfg_table_elem->dw13.bs.cfg_rq_depth;
> >> +	case QUEUE_NUM:
> >> +		return funcfg_table_elem->dw13.bs.cfg_q_num;  
> > 
> > The first two patches look fairly unobjectionable to me, but here the
> > information does not seem that driver-specific. What's vlan_mode, and
> > vlan_id in the context of PF? Why expose mtu, is it different than
> > netdev mtu? What's valid? rq_depth?
> > .
> >   
> The vlan_mode and vlan_id in function table are provided for VF in QinQ scenario
> and they are useless for PF. Querying VF's function table is unsupported now, so
> there is no need to expose vlan_id and vlan mode and I'll remove them in my next
> patchset. The function table is saved in hw and we expose the mtu to ensure the
> mtu saved in hw is same with netdev mtu. The valid filed indicates whether this
> function is enabled or not and the hw can judge whether the RQ buffer in host is
> sufficient by comparing the values of rq depth, pi and ci.

Queue depth is definitely something we can add to the ethtool API.
You already expose raw producer and consumer indexes so the calculation
can be done, anyway.