From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 4271B3DC for ; Tue, 13 Dec 2016 18:31:07 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP; 13 Dec 2016 09:31:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,342,1477983600"; d="scan'208";a="1081327699" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by fmsmga001.fm.intel.com with ESMTP; 13 Dec 2016 09:31:02 -0800 To: "Ananyev, Konstantin" , Michal Miroslaw References: <2601191342CEEE43887BDE71AB9772583F0E6E4C@irsmsx105.ger.corp.intel.com> <20161213142654.me3p5gl7muji3sei@rere.qmqm.pl> <2601191342CEEE43887BDE71AB9772583F0E70A6@irsmsx105.ger.corp.intel.com> <20161213145742.hxvtr63anhy7ai33@rere.qmqm.pl> <2601191342CEEE43887BDE71AB9772583F0E754B@irsmsx105.ger.corp.intel.com> Cc: "dev@dpdk.org" From: Ferruh Yigit Message-ID: <712f94f8-0ea2-a1e0-8fc0-f45d765a203b@intel.com> Date: Tue, 13 Dec 2016 17:31:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E754B@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities 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: Tue, 13 Dec 2016 17:31:08 -0000 On 12/13/2016 5:12 PM, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl] >> Sent: Tuesday, December 13, 2016 2:58 PM >> To: Ananyev, Konstantin >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities >> >> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote: >>> >>> >>>> -----Original Message----- >>>> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl] >>>> Sent: Tuesday, December 13, 2016 2:27 PM >>>> To: Ananyev, Konstantin >>>> Cc: dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities >>>> >>>> On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote: >>>>>> -----Original Message----- >>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw >>>>>> Sent: Tuesday, December 13, 2016 1:08 AM >>>>>> To: dev@dpdk.org >>>>>> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities >>>>>> >>>>>> From: Paweł Małachowski >>>>>> >>>>>> Thanks to that change we can use Null PMD for testing purposes. >>>>>> >>>>>> Signed-off-by: Michał Mirosław >>>>>> --- >>>>>> drivers/net/null/rte_eth_null.c | 13 ++++++++++++- >>>>>> 1 file changed, 12 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c >>>>>> index 836d982..f32ba2a 100644 >>>>>> --- a/drivers/net/null/rte_eth_null.c >>>>>> +++ b/drivers/net/null/rte_eth_null.c >>>>>> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id, >>>>>> return 0; >>>>>> } >>>>>> >>>>>> +static void >>>>>> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; } >>>>>> + >>>>>> >>>>>> static void >>>>>> eth_dev_info(struct rte_eth_dev *dev, >>>>>> @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev, >>>>>> dev_info->pci_dev = NULL; >>>>>> dev_info->reta_size = internals->reta_size; >>>>>> dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads; >>>>>> + /* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking >> packets in >>>>>> /dev/null */ >>>>>> + dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP; >>>>>> + dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM; >>>>> >>>>> Hmm, how could it be supported if all that null PMD does on TX - just free the packets? >>>>> Same question for RX. >>>> >>>> You could imagine, that before dropping the packet you insert the tag >>>> and calculate the checksum. The observed effect will be the same. >>>> >>>> On RX this always indicates lack of VLAN tag. So whether the offload >>>> is enabled or not it doesn't matter. >>> >>> Of course user can imagine whatever he likes, but what the point to advertise these capabilities, >>> when the PMD clearly doesn't have them? >>> Again, why these particular ones? >> >> Hmm. I guess we can expand the set. Those were the ones we actually use >> (depend on) for testing our code. >> >> This allows to use null PMD for testing in place of real network interface >> with those offloads. > > As I can see on TX null pmd would just drop the packets, right? > So the only thing you might check, as I understand, did upper layer code > setup ol_flags and other mbuf fields properly depending on advertised capabilities > (probably via sme special tx_callback installed or so). > Is that correct? > That's ok, I suppose, but if tomorrow you (or someone else) would like to test > with different RX/TX offloads? > Shouldn't be advertised offload capabilities be configurable at device creation/attach time > somehow? This sounds good. Getting offload capabilities on runtime as devargs. > Or at least just advertise all possible ones then? > > Konstantin > >> This patch is to keep users from having to place if's >> around their code just to support test scenarios with null PMD. >> >> Best Regards, >> Michał Mirosław