[dpdk-dev] [PATCH v2 2/3] doc: add vDPA feature table

[Thomas Monjalon]

09/01/2020 12:00, Matan Azrad:
> +This section explains the supported features that are listed in the table below.
> +
> +  * csum - Device can handle packets with partial checksum.
> +  * guest csum - Guest can handle packets with partial checksum.
> +  * mac - Device has given MAC address.
> +  * gso - Device can handle packets with any GSO type.
> +  * guest tso4 - Guest can receive TSOv4.
> +  * guest tso6 - Guest can receive TSOv6.
> +  * ecn - Device can receive TSO with ECN.
> +  * ufo - Device can receive UFO.
> +  * host tso4 - Device can receive TSOv4.
> +  * host tso6 - Device can receive TSOv6.
> +  * mrg rxbuf - Guest can merge receive buffers.
> +  * ctrl vq - Control channel is available.
> +  * ctrl rx - Control channel RX mode support.
> +  * any layout - Device can handle any descriptor layout.
> +  * guest announce - Guest can send gratuitous packets.
> +  * mq - Device supports Receive Flow Steering.
> +  * version 1 - v1.0 compliant.
> +  * log all - Device can log all write descriptors (live migration).
> +  * indirect desc - Indirect buffer descriptors support.
> +  * event idx - Support for avail_idx and used_idx fields.
> +  * mtu - Host can advise the guest with its maximum supported MTU.
> +  * in_order - Device can use descriptors in ring order.
> +  * IOMMU platform - Device support IOMMU addresses.
> +  * packed - Device support packed virtio queues.
> +  * proto mq - Support the number of queues query.
> +  * proto log shmfd - Guest support setting log base.
> +  * proto rarp - Host can broadcast a fake RARP after live migration.
> +  * proto reply ack - Host support requested operation status ack.
> +  * proto host notifier - Host can register memory region based host notifiers.
> +  * proto pagefault - Slave expose page-fault FD for migration process.
> +  * BSD nic_uio - BSD ``nic_uio`` module supported.
> +  * Linux VFIO - Works with ``vfio-pci`` kernel module.
> +  * Other kdrv - Kernel module other than above ones supported.
> +  * ARMv7 - Support armv7 architecture.
> +  * ARMv8 - Support armv8a (64bit) architecture.
> +  * Power8 - Support PowerPC architecture.
> +  * x86-32 - Support 32bits x86 architecture.
> +  * x86-64 - Support 64bits x86 architecture.
> +  * Usage doc - Documentation describes usage, In ``doc/guides/vdpadevs/``.
> +  * Design doc - Documentation describes design. In ``doc/guides/vdpadevs/``.
> +  * Perf doc - Documentation describes performance values, In ``doc/perf/``.

It may be appropriate to use the RST syntax for definitions:
	https://docutils.sourceforge.io/docs/user/rst/quickref.html#definition-lists

Andrew proposed to describe each feature with the same properties as for ethdev:
	http://code.dpdk.org/dpdk/latest/source/doc/guides/nics/features.rst
You replied that it would be redundant for each feature.
In order to be more specific, the ethdev feature properties are:
	- [uses] = input fields and constants
	- [implements] = dev_ops functions
	- [provides] = output fields
	- [related] = API function

The API is very simple:
	http://code.dpdk.org/dpdk/latest/source/lib/librte_vhost/rte_vdpa.h
The relevant dev_ops are written in the below note.

> +.. note::
> +
> +   Most of the features capabilities should be provided by the drivers via the
> +   next vDPA operations: ``get_features`` and ``get_protocol_features``.

I don't see what else can be filled in [uses], [implements] and [provides]
in the case of vDPA, so I suggest to keep it simple as it is.