On Fri, 28 Aug 2020 11:16:22 +0800 luobin (L) wrote:

On 2020/8/28 3:44, Jakub Kicinski wrote:

quoted

On Thu, 27 Aug 2020 19:13:21 +0800 Luo bin wrote:  

quoted

+	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.