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 92161A00BE; Fri, 15 May 2020 18:26:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BAF561DADD; Fri, 15 May 2020 18:26:45 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 3CF4A1DA9B for ; Fri, 15 May 2020 18:26:44 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id d7so3358849ioq.5 for ; Fri, 15 May 2020 09:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XwOVAbb9hTHy0GzDEjj8LHR6DtTp3eImBZqco8eSqFA=; b=epAeNolrHTf3r1M7Di23XkI/xNCE5JMxFPlSNOBY6NucBzaJ0OLOGLOkbNPW4mHxjq WyF0A8lKv2wZpKNDE6nnwHZpE/eNC5GFipeIWyq1bepakJ79LWbT8063vubtgX4t/EXq bsycQBiCrw+izrBlo5qYotnDAonnMXVQbEniGpcPu0veXuUlXgISHCiC/AQUc7MzBts4 DQZPOzB4YDWC1auUOMJfB6tHi8OZtFUYaMBpT9wfuaTuPhL0c60Q1ncsXYTNeQ7L3qIF exL88OyIGELKqqiS5jHFW+bfWPsS+8ya5cAWipZ9DgVe5nKQj592P8ggmG9aI1zYSvXU tMgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XwOVAbb9hTHy0GzDEjj8LHR6DtTp3eImBZqco8eSqFA=; b=NzIyfVJc2L6Y+d+waVkzcyM/9ssH8r59vmBnyc91pWYAsOVzJ3sK5WOsvW/HJI9dfF jzg8r+I8IeCRN1VdWhgfDm7b9/7ELxuir9oFBNj89+JLjnX6pHH1PpmyVi0qFB03dCwk N6+gF5CoEaI+aCAuSx2KrFRs6U1TJuKCsxNsi0C7y/cUVtmNGKEzkQBjEzLJYF2pcvnO CQHWA2YYekee1YbF67AnvY74kzxPkJselxGI0QybKh4eTWGoBGq8hdvdK40tFB2VJK+v EAMf2IQWLqosu4ffbWWFM7yeEcH8Pv8aB4nAjDzavkW4DPT1cs3Im/+I0fHCtlVc86dN XAVg== X-Gm-Message-State: AOAM532Zgp7Xuay8q8WeaASO3hFpOCWzoeBh5xaiO3iwnC1cHKFpmnRF KgEH7stc8MaFq+/0zb83rDXfbgjny1cX+PqZxrY= X-Google-Smtp-Source: ABdhPJzxXd983yV95hNK5WE6mdHQYRvFVuK4WyubgOtsaR+TIgz0IFnu9AS3l35t0I+EYuWPb+g67Yozlfcu4Ra/iLI= X-Received: by 2002:a5e:9904:: with SMTP id t4mr3663606ioj.59.1589560003271; Fri, 15 May 2020 09:26:43 -0700 (PDT) MIME-Version: 1.0 References: <20200417072254.11455-1-nithind1988@gmail.com> <2214992.9fHWaBTJ5E@thomas> <20200515134420.GA9696@outlook.office365.com> <16221090.5WZRyvrzyv@thomas> In-Reply-To: <16221090.5WZRyvrzyv@thomas> From: Jerin Jacob Date: Fri, 15 May 2020 21:56:26 +0530 Message-ID: To: Thomas Monjalon Cc: Nithin Dabilpuram , Olivier Matz , Nithin Dabilpuram , Ferruh Yigit , Andrew Rybchenko , Ori Kam , Cristian Dumitrescu , Anatoly Burakov , John McNamara , Marko Kovacevic , dpdk-dev , Jerin Jacob , Krzysztof Kanas Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for packet marking 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 Fri, May 15, 2020 at 8:40 PM Thomas Monjalon wrote: > > 15/05/2020 15:44, Nithin Dabilpuram: > > On Fri, May 15, 2020 at 03:12:59PM +0200, Thomas Monjalon wrote: > > > 15/05/2020 12:08, Nithin Dabilpuram: > > > > On Thu, May 14, 2020 at 10:29:31PM +0200, Olivier Matz wrote: > > > > > I don't see any better approach than having a mbuf flag. However, I'm > > > > > still not fully convinced that a dynamic flag won't do the job. Taking > > > > > 3 additional flags (among 18 remaing) for this feature also means that > > > > > we have 3 flags less for dynamic flags for all applications, even for > > > > > applications that will not use this feature. > > > > > > > > > > Would it be a problem to use a dynamic flag in this case? > > > > Since packet marking feature itself is already part of spec, > > > > if we move the flags to PMD specific dynamic flag, then it creates a confusion. > > > > > > > > It is not the case of a custom feature supported by a specific PMD. > > > > I believe when other PMD's implement packet marking, the same flags will > > > > suffice. > > > > > > A dynamic flag is not necessarily PMD-specific. > > > It is just avoiding consuming bits if the feature is not used by the application. > > > We must move more existing flags and fields to be dynamic. > > > > > > In general, all new flags and fields in mbuf should be dynamic. > > > And a work must be done to move existing stuff to free more space > > > for more dynamic features. > > > > My bad, I thought dynamic flags can only be used for PMD specific thing. > > > > There is however a cost of using dynamic flag which I think should be avoided > > for DPDK spec defined offloads, though it's fine for PMD specific things. > > > > Dynamic offload flags causes application and PMD to use non constant offset > > or shift which are looked up at init, instead of having a constant shift or > > offset. This indirection costs some cycles due to extra loads in fast path. > > Yes there is a cost. We described it quite clearly last year. > The default rule is now to add new flags and fields as dynamic. > In case the rule was not clear, I will send a patch to insert some > notes in the code and the doc. Yes. Please send a patch to document the rule. That makes life easy for everyone to make a boolean decision. Here is the comment from mbuf: support dynamic fields and flags commit when accepted this patch. " The typical use case is a PMD that registers space for an offload feature, when the application requests to enable this feature. As the space in mbuf is limited, the space should only be reserved if it is going to be used (i.e when the application explicitly asks for it). " If you are pushing this feature to dynamic mbuf filed then rte_tm subsystem needs to register dynamic field not the PMD as the feature is part of rte_tm spec. > > If you disagree with this new rule, you will have to give very good arguments. What would the definition of a good argument? as the same logic can be implemented with dynamic vs static at the cost of dynamic indirection. > > > >