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

["luobin (L)" <luobin9@huawei.com>]

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.