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 1722CCA9EA0 for ; Fri, 18 Oct 2019 08:18:57 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id AC77A21925 for ; Fri, 18 Oct 2019 08:18:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC77A21925 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 168FC1C033; Fri, 18 Oct 2019 10:18:56 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2C8A41C02F for ; Fri, 18 Oct 2019 10:18:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2019 01:18:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,311,1566889200"; d="scan'208";a="200644701" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.10]) ([10.237.221.10]) by orsmga006.jf.intel.com with ESMTP; 18 Oct 2019 01:18:51 -0700 From: Ferruh Yigit To: Bruce Richardson Cc: Andrew Rybchenko , 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> 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 09:18:50 +0100 MIME-Version: 1.0 In-Reply-To: <983d5c2f-e287-ccc2-5d7d-0b56e9b2da3a@intel.com> 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/17/2019 4:33 PM, 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. > > Perhaps application should differentiate between -ENOTSUP error and operation > fail error, but that looks to me adding unnecessary complexity to the app. > > With a common function shared by all PMDs for both promisc and allmuticast will > add a little code and an easier solution. > btw, initialize promiscuous as enabled at PMD init won't help with current APIs because in API dev_ops check is earlier and will still cause -ENOTSUP. rte_eth_promiscuous_enable RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->promiscuous_enable, -ENOTSUP); if (dev->data->promiscuous == 0) diag = (*dev->dev_ops->promiscuous_enable)(dev); dev->data->promiscuous = (diag == 0) ? 1 : 0; return