From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id BE1B3374 for ; Fri, 7 Jul 2017 17:06:56 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2017 08:06:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,323,1496127600"; d="scan'208";a="1169900459" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.91]) ([10.237.220.91]) by fmsmga001.fm.intel.com with ESMTP; 07 Jul 2017 08:06:53 -0700 To: Andrew Rybchenko , John McNamara Cc: dev@dpdk.org, Olivier Matz References: <20170622190233.67933-1-ferruh.yigit@intel.com> <20170705132028.58993-1-ferruh.yigit@intel.com> <8a981e9a-2215-a2ae-cb75-5982fd714845@solarflare.com> From: Ferruh Yigit Message-ID: <199b9881-26d4-f36d-9737-02b8559d449e@intel.com> Date: Fri, 7 Jul 2017 16:06:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8a981e9a-2215-a2ae-cb75-5982fd714845@solarflare.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] doc: document NIC features 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: , X-List-Received-Date: Fri, 07 Jul 2017 15:06:57 -0000 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. <...>