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=-3.3 required=3.0 tests=BAYES_00,DKIM_ADSP_DISCARD, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 33822C4338F for ; Mon, 2 Aug 2021 19:19:39 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 5C30D60EE8 for ; Mon, 2 Aug 2021 19:19:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5C30D60EE8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8075941147; Mon, 2 Aug 2021 21:19:37 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0177A40140 for ; Mon, 2 Aug 2021 21:19:35 +0200 (CEST) Received: from [192.168.100.116] (unknown [37.139.99.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id E4E3E7F50A; Mon, 2 Aug 2021 22:19:34 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru E4E3E7F50A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1627931975; bh=/e2rCKP9fRnDmaKa5SubFk/F4zbF8RJrgSCV8cjw3yM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tuEd0OptsmaMKgO6KA9FFln5MTPC063OXYHeh+RjKC3Q5/rM81aEVd/MhIykzo03+ YK23UqWmQ99LB3CTHLZNs+Us5ApDV4kRX/Hb5fg/9msw5QfjYKXAk4vXA6RP8k1eHK GRMCtcbR8Ou61hwh504E9Wi4+oyKPbClpRZSdaZs= To: Ilya Maximets , Thomas Monjalon , Ferruh Yigit , Ori Kam Cc: dev@dpdk.org, Eli Britstein , Ajit Khaparde , Matan Azrad , Ivan Malov , Viacheslav Galaktionov References: <20210801102214.1566104-1-andrew.rybchenko@oktetlabs.ru> <5664df76-33c7-773b-73f8-641af2535c7e@ovn.org> From: Andrew Rybchenko Message-ID: Date: Mon, 2 Aug 2021 22:19:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5664df76-33c7-773b-73f8-641af2535c7e@ovn.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: announce flow API action PORT_ID changes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 8/2/21 6:49 PM, Ilya Maximets wrote: > On 8/1/21 12:22 PM, Andrew Rybchenko wrote: >> By its very name, action PORT_ID means that packets hit an ethdev with the >> given DPDK port ID. At least the current comments don't state the opposite. >> That said, since port representors had been adopted, applications like OvS >> have been misusing the action. They misread its purpose as sending packets >> to the opposite end of the "wire" plugged to the given ethdev, for example, >> redirecting packets to the VF itself rather than to its representor ethdev. >> Another example: OvS relies on this action with the admin PF's ethdev port >> ID specified in it in order to send offloaded packets to the physical port. > > Hi, Andrew. The deprecation notice itself looks OK to me. But I'd suggest > to avoid words like "misuse" and "misread" in the commit message, because I > don't think that it's correct. Since documentation is ambiguous, different > people might interpret it differently. And also, implementation in DPDK > matches with the way how OVS uses the API, otherwise offloading in OVS would > just not work. So, OVS uses this API in a way as it is implemented in DPDK. > If the definition of a DPDK API allows interpretations that doesn't match with > the implementation inside the DPDK itself, that's not a fault of the external > application. And this can not be labeled as "misuse"/"misread". Let's not > create a precedent. Yes, I agree. I'll send v2 tomorrow. Thanks for feedback, Andrew.