From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 92847A00E6 for ; Wed, 7 Aug 2019 17:22:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6C43A2E8F; Wed, 7 Aug 2019 17:22:24 +0200 (CEST) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id AD58B2BBD for ; Wed, 7 Aug 2019 17:22:23 +0200 (CEST) Received: by mail-pl1-f196.google.com with SMTP id a93so41256198pla.7 for ; Wed, 07 Aug 2019 08:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=k8B4aYqoCndDZ/c828vRUIzuRC4qcY9NZlhI6hUrstc=; b=JYCfe3z9FIZNmMFXGgWzV5qBBwYsf+XDkyiRKy39u029e+Y9k67fGzjCttmZ4xdhRq 6ZDGbBCLb5NHGBPJ9pGuyw1kuF4G1mAz9SzGBMTbrn80SvAE/oIZbNTGAX2BvWZWQ4AN MjRx56Xj3rqMyThqotYwpC0W4bzs7HGVuSuGr+ijyLMDQU3w+AzU/RXdlsQ8JqFhybXF 57vUsUxacYwTIt/jqtJFmOWBBzYT0GwtF4NvJNmm65/IegnnJn9K2pE/GxeRUj/G4U5O u9VJGgjT7uJmDqI7ITZr+VHj59hxC6uG/bplW0W2k80OegBGhVGqcks3n9Kocmd9vkwU RXZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=k8B4aYqoCndDZ/c828vRUIzuRC4qcY9NZlhI6hUrstc=; b=HdLeYllTcHTv0CQROHlBmCmNyT1Oa6Pwhv6BxoO1rArl0cPtEtjMojBTeVV2DMHILB VOh3QKlKzrKY10J+CbAmeNqfqDEVVKKyRtWveBLq5n7yqEfAuUVDndfkTpKrSgePPe6b l3rpS4qahM1J6eqbihOVZqJNNdAizG/hPKKHADmZ5HIzPNM8ox5x5skM/MoA1T/iwdeb 0cetAez5mX0Oca7aWBuEPrnRpFPx1n5KCKd3Gu6qUN73n6o3f5mmVAqB+9qfFeSeeDXU 9df6W0mJbGlSXzhInh8qxmRt0h0HdZa6Gys05vil4KdTlC0rdEVnZrU32llFNAJAjsdB y2vA== X-Gm-Message-State: APjAAAX0B57OxIec+vSrGDGv8cQNLSIHh1HJMGrIyVH0Qp5K9wizfcfZ Sh/pBQ1wVkwc1m/WQC6893IhzQ== X-Google-Smtp-Source: APXvYqz8Dk6VH/EqFaBPJORD+nHYoWU+pwY2sIgvBF7nDZ9kDkbYa9Txcwfq/jnLydBAWRge9O32Jw== X-Received: by 2002:a62:1750:: with SMTP id 77mr9962797pfx.172.1565191342825; Wed, 07 Aug 2019 08:22:22 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id p13sm359657pjb.30.2019.08.07.08.22.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 07 Aug 2019 08:22:22 -0700 (PDT) Date: Wed, 7 Aug 2019 08:22:15 -0700 From: Stephen Hemminger To: Andrew Rybchenko Cc: Jerin Jacob Kollanukkaran , Pavan Nikhilesh Bhagavatula , Hemant Agrawal , "dev@dpdk.org" Message-ID: <20190807082215.0ef3f6ae@hermes.lan> In-Reply-To: <5ebb1ff8-3f44-c1ab-ead7-64727e0dd0a6@solarflare.com> References: <5ebb1ff8-3f44-c1ab-ead7-64727e0dd0a6@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload 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 Wed, 7 Aug 2019 11:32:35 +0300 Andrew Rybchenko wrote: > On 8/7/19 5:04 AM, Jerin Jacob Kollanukkaran wrote: > >> -----Original Message----- > >> From: Stephen Hemminger > >> Sent: Wednesday, August 7, 2019 4:45 AM > >> To: Andrew Rybchenko > >> Cc: Pavan Nikhilesh Bhagavatula ; Hemant > >> Agrawal ; Jerin Jacob Kollanukkaran > >> ; dev@dpdk.org > >> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload > >> > >> On Tue, 6 Aug 2019 12:06:35 +0300 > >> Andrew Rybchenko wrote: > >> > >>> On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote: > >>>>> -----Original Message----- > >>>>> From: Hemant Agrawal > >>>>> Sent: Tuesday, August 6, 2019 1:49 PM > >>>>> To: Pavan Nikhilesh Bhagavatula ; Jerin > >>>>> Jacob Kollanukkaran > >>>>> Cc: dev@dpdk.org > >>>>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload > >>>>>> Add PTYPE to DEV_RX_OFFLOAD_* flags. > >>>>>> > >>>>>> Currently, most of the NICs already support PTYPE parsing and > >>>>>> update > >>>>> the > >>>>>> mbuf->packet_type through an internal lookup table, but there is > >>>>>> mbuf->no > >>>>> way to > >>>>>> disable the lookup if the application is not intrested in ptypes > >>>>> returned by > >>>>>> `rte_eth_dev_get_supported_ptypes`. > >>>>>> > >>>>> [Hemant] it will also mean introducing another check in datapath, > >>>>> if the application has asked for PTYPE offload - copy the results > >>>>> to mbuf- > >>>>>> packet_type otherwise don't do it. > >>>> I think that having the check would give better performance than > >>>> loading ptype table to L1 doing a lookup and copying it to mbuf when the > >> application doesn't need it. > >>> Anyway, if PMD decides that it is better to always provide packet type > >>> information - there is no harm. Basically if the offload is not > >>> requested it makes packet_type undefined in mbuf. > >>> > >>>>> Your second patch is incomplete in the sense that it only adds the > >>>>> capability. But it does not disable the lookups? > >>>> It is upto the maintainer of the PMD to disable the lookup in data > >>>> path. If there is a scope of optimization then they could do it. There is no > >> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled. > >>>> I was hesitant to touch data path as it would be impossible to verify > >> performance effect on all NICs. > >>> I think it is the right way to approach it especially taking > >>> transition into account. > >>> > >> With hardline API policy, this has to fail on compile for old applications. > > Stephen, could you explain a bit more why. Existing releases packets will be received with ptype for hardware that supports it. We should not require users to change their application to continue to get mbufs with ptype. If your change would break that, and require application to change; then your change should break the API in a hard way that causes compile rather than runtime failure. The best solution would be to just keep old applications running and compiling without breaking anything. That means ptype should still be received. If (as an optimization) you want to allow application to turn of getting ptype; then that would be a useful. Probably best done at the port level as part of configuration. > > > Not specific to this API change. That's is the propriety any new symbol addition > > to the code base. > > > > Planning to make this API change available fromv19.11 LTS. > > The only way to to require applications to enable PTYPE offload to get > ptypes in mbuf since 19.11 LTS is to have deprecation notice in 19.08. > > >> You can't magically assume that applications using ptype will set new feature. > > When OFFLOAD flags got introduced, we decided to disable all offloads by default. > > So, need to add positive logic here to enable offload instead of enable something by > > Default and disable if required to get have synergy with other offloads. > > > > Will update the release note as usual to document the change. > > Since there is NO ABI change, IMO, we don't need deprecation notice. > > Sorry, but it is a behaviour change. Before an application does not need > to enable ptype offload, but now it is required. It means that application > will be broken and, therefore, it requires deprecation notice. The DPDK development community has to make not breaking applications a higher priority than adding marginal enhancements