On 7/7/2017 11:55 AM, Andrew Rybchenko wrote: <...> >> +TSO >> +--- >> + >> +Supports TCP Segmentation Offloading. >> + >> +* **mbuf**: ``mbuf.ol_flags:PKT_TX_TCP_SEG``. > > DEV_TX_OFFLOAD_*_TSO in tx_offload_capa > Is support of one TSO option sufficient to say Yes?
This is common question for a few offload features, like ones that can be valid for Rx and Tx path, I guess feature should be "Yes" if all are supported, otherwise "P(artial)". But this is hard to trace and if marked as "P", makes hard to figure out what is supported. <...> >> +SR-IOV >> +------ >> + >> +Driver supports creating Virtual Functions. > > Does it mean VFs control or PMD can work on VF? I don't know. This option is not very clear, and need to be agreed on. If this is to say driver controls VF, for some drivers PF and VF version documented separately already, so this feature becomes redundant. And for some drivers, same driver supports both PF and VF, and represented as single column in table, so how you can use this field? I thought this is to say device has SR-IOV support, for that case this only makes sense for PF drivers and VF shouldn't set this. Target is to provide some kind of useful information about device, what it can be for this case? <...> >> +VLAN filter >> +----------- >> + >> +Supports filtering of a VLAN Tag identifier. >> + >> +* **eth_dev_ops**: ``vlan_filter_set``. >> +* **API**: ``rte_eth_dev_vlan_filter()``. > > dev_conf.rxmode.hw_vlan_filter ? > > It should be clarified the difference to VLAN offload, since > hw_vlan_filter is mentioned below. dev_conf.rxmode.hw_vlan_filter looks like used in the rte_eth_dev_set_vlan_offload() API. I am confused about "vlan filter" and "vlan offload". I need to check implementation more to be able to clarify it, but for now keeping option in other feature. <...>
