From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 88C39A04F9; Fri, 10 Jan 2020 19:26:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2F9BE1EB89; Fri, 10 Jan 2020 19:26:35 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 46ABB1EB84 for ; Fri, 10 Jan 2020 19:26:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2620021C46; Fri, 10 Jan 2020 13:26:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 10 Jan 2020 13:26:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=4wa5Zc/4QQ+D6DlDlNCTPUyBDWMCKMgAyJVfDEjVfVg=; b=hzJ0xjNWdfpj eJb+h9dxRzxka9it5e8ZyIza4nGO3Sh9UE/tdm1lmhCeZ89TAvbnGuw3LVPB8NH0 UnU/ytXSkwm/K7trImQXc9EaUz8zhG6L6L1GkcKlox/WRRauA04MB/BowETL18wg AnJzTdaBAVtmw04nyStCbW8Y4I4NUR0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=4wa5Zc/4QQ+D6DlDlNCTPUyBDWMCKMgAyJVfDEjVf Vg=; b=jgHzx/EdP7p5Ne0+gf+XSLR4jK414Otghz+WZCD1kQ8RVWOgfnq0aD4D5 iYVuEOOPjqXbQv3k8QY5H9aIYmslT3cBzknIB9913T+FO96A9R5v/+aE65s4qtOp BHY+TASrBYo3ySnJTSEzJq13NCWPbUOZkKZYYSAP5JkG5tOLhy+9xiO6VCUkwK3T hofDHEDkuMaw1Y0s394ycAEtZ5zYE5u0AxutmyBhzkd/0J7SZyy9/0UqH7mLC4ir bcqN6QVyMGDPWPljoX5v+UOALO+zO5uIllXCORPMnfb3VdKA0IeIGsc3bagXQgEk fKFp40H5IxY78rsllW4h98PsBnynA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeifedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ffohhmrghinhepshhouhhrtggvfhhorhhgvgdrihhopdguphgukhdrohhrghenucfkphep jeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomh grshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 391A230600A8; Fri, 10 Jan 2020 13:26:28 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko , Matan Azrad Cc: Maxime Coquelin , Tiwei Bie , Zhihong Wang , Xiao Wang , dev@dpdk.org, Ferruh Yigit , dev@dpdk.org Date: Fri, 10 Jan 2020 19:26:26 +0100 Message-ID: <2086499.3ZeAukHxDK@xps> In-Reply-To: <1578567617-3541-3-git-send-email-matan@mellanox.com> References: <1577287161-10321-1-git-send-email-matan@mellanox.com> <1578567617-3541-1-git-send-email-matan@mellanox.com> <1578567617-3541-3-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 2/3] doc: add vDPA feature table X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.