From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B429DCA9EA1 for ; Fri, 18 Oct 2019 13:02:09 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 4B3FD2089C for ; Fri, 18 Oct 2019 13:02:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B3FD2089C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 160D91C1A1; Fri, 18 Oct 2019 15:02:08 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id D0C6D1C192 for ; Fri, 18 Oct 2019 15:02:05 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2019 06:02:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,311,1566889200"; d="scan'208";a="348071866" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.10]) ([10.237.221.10]) by orsmga004.jf.intel.com with ESMTP; 18 Oct 2019 06:02:02 -0700 To: Andrew Rybchenko , Bruce Richardson Cc: Ciara Power , mtetsuyah@gmail.com, dev@dpdk.org, Thomas Monjalon References: <20191016154606.39218-1-ciara.power@intel.com> <5b6af628-7101-484b-01db-16272025105f@solarflare.com> <04b0cc0a-633f-212e-22ab-147b7f3e6a1a@intel.com> <20191017134341.GA912@bricha3-MOBL.ger.corp.intel.com> <983d5c2f-e287-ccc2-5d7d-0b56e9b2da3a@intel.com> <20191018101357.GA919@bricha3-MOBL.ger.corp.intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: Date: Fri, 18 Oct 2019 14:02:01 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC] net/null: add empty promiscuous mode functions 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" On 10/18/2019 12:57 PM, Andrew Rybchenko wrote: > On 10/18/19 2:38 PM, Ferruh Yigit wrote: >> On 10/18/2019 11:13 AM, Bruce Richardson wrote: >>> On Thu, Oct 17, 2019 at 04:33:59PM +0100, Ferruh Yigit wrote: >>>> On 10/17/2019 2:43 PM, Bruce Richardson wrote: >>>>> On Thu, Oct 17, 2019 at 12:05:56PM +0100, Ferruh Yigit wrote: >>>>>> On 10/17/2019 11:51 AM, Andrew Rybchenko wrote: >>>>>>> On 10/17/19 1:47 PM, Ferruh Yigit wrote: >>>>>>>> On 10/17/2019 11:37 AM, Andrew Rybchenko wrote: >>>>>>>>> On 10/16/19 9:07 PM, Ferruh Yigit wrote: >>>>>>>>>> On 10/16/2019 4:46 PM, Ciara Power wrote: >>>>>>>>>>> Adding promiscuous functions prevents sample applications failing when run >>>>>>>>>>> on this virtual PMD. The sample applications call promiscuous functions, >>>>>>>>>>> and fail if this function call returns an error, which occurs when the >>>>>>>>>>> virtual PMD does not support the promiscuous function being called. >>>>>>>>>>> >>>>>>>>>>> This change will be implemented for all virtual PMDs that currently do not >>>>>>>>>>> have existing promiscuous functions. Multicast functions will also be >>>>>>>>>>> added for virtual PMDs to prevent sample application breakages here also. >>>>>>>>>> +Andrew >>>>>>>>>> >>>>>>>>>> With the some ethdev APIs returning error code, some sample applications stop >>>>>>>>>> working with virtual interfaces, >>>>>>>>>> >>>>>>>>>> We can, >>>>>>>>>> 1- update sample applications to ignore the errors >>>>>>>>>> 2- Add dummy dev_ops support to (almost all) virtual PMDs (what this RFC suggests) >>>>>>>>>> >>>>>>>>>> (1) puts us back to before the ethdev APIs updated status, and this may be wrong >>>>>>>>>> for the physical devices case, so I am for this RFC. >>>>>>>>>> >>>>>>>>>> Only perhaps we can have some common empty function and keep assigning that one >>>>>>>>>> to reduce the dummy code, what do you think? >>>>>>>>> I don't like the idea to have common empty/dummy functions. >>>>>>>>> If virtual PMD behaves in accordance with enabled promiscuous mode, >>>>>>>>> it should initialize it properly on init: >>>>>>>>>      eth_dev->data->promiscuous = 1; >>>>>>>>> If so, if application requires promiscuous mode, attempt to enable will >>>>>>>>> do nothing. If application requires non-promiscuous mode, disable will >>>>>>>>> fail and it is good. >>>>>>>> It is technically correct that we can't disable promiscuous mode in virtual PMDs >>>>>>>> but I think mainly we don't really care so it returning error may make the >>>>>>>> applications fail/exit unnecessarily with virtual PMDs. >>>>>>> If I test virtual PMD promiscuous mode, I would prefer enable/disable >>>>>>> callback to say me truth. >>>>>>> >>>>>>> If application really does not care, it should be in the application code. >>>>>> Application can't change this because they may be caring return result for the >>>>>> physical devices. >>>>>> >>>>>> Up until this release these missing dev_ops in virtual PMDs were silently >>>>>> ignored, now APIs are more strict on this (which is good) but to get close the >>>>>> previous behavior for virtual PMDs we need to relax on these features (like >>>>>> saying success on promiscuous disable although it didn't). >>>>>> >>>>> The other variable here is how often an app is going to request promiscuous >>>>> disabling? Given that most ports generally come up in that state anyway, >>>>> and one needs to request enabling it, surely the disable case is relatively >>>>> rare? In that case I'd tend to agree with having disabling it returning >>>>> error for vpmds. >>>>> >>>> Yes disabling most probably rare, but still it will generate an error and >>>> application is failing because of ring PMD promiscuous disable doesn't look >>>> right to me. >>> Well, if an app needs promiscuous mode disabled then having it fail is the >>> right thing to do. If the app doesn't care about promiscuous mode failing, >>> why is it checking the return value at all? >>> >>>> Perhaps application should differentiate between -ENOTSUP error and operation >>>> fail error, but that looks to me adding unnecessary complexity to the app. >>>> >>> Again, does the app care or not? It's probably still better to return >>> correct info to the app in all cases, and then let the app decide how best >>> to handle it. >> My thinking is, application "cares" about the ethdev API return values, but to >> check/test quickly with null/ring PMD perhaps not really care that much abut >> promisc/allmuticast support of these PMDs and let's relax these support of >> virtual PMDs to make life easy. >> >> But eventually the main target is to fix sample applications to run with virtual >> PMDs which has been broken in this release. >> Both approach works, >> a) Implement dummy dev_ops to virtual PMDs to report success >> b) Update ethdev APIs to not call dev_ops if the requested configuration is >> already satisfied and change virtual PMDs to report promisc & allmulticast >> enabled by default. (disable still will have same issue) >> >> Is the consensus option (b)? > > Yes. > >> btw, the problem exists in high level for the offload support, if the >> application is requesting a specific offload support it fails to run with the >> virtual PMDs since virtual PMDs doesn't support any offloads. Indeed I have same >> suggestion for this case too, relax the virtual PMD by claiming it supports all >> offloads. Because at least for me when I use those virtual PMDs I don't really >> would like to test offloads or the procmisc/allmulticast features ... > > It looks like I simply don't understand virtual PMDs usacase. I guess it changes for virtual PMD, bonding, failsafe, vhost, etc has more production use cases, null I would assume mostly used for debugging. > >>>> With a common function shared by all PMDs for both promisc and allmuticast will >>>> add a little code and an easier solution. >