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 4CFE2A0563; Wed, 15 Apr 2020 13:25:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B0AB1D6DB; Wed, 15 Apr 2020 13:25:57 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 19E5A1D6D7; Wed, 15 Apr 2020 13:25:56 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id a201so18158958wme.1; Wed, 15 Apr 2020 04:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=DCVwl/sbF+bx2hwvIJa2nePDwMvFBppFueR05iJAGN0=; b=GXtW/9oL8puMWOx/PHfNADbEm5u5kciFZS+aPM3882p8OLabVkth/wjRIeql+/KX9i vq1SC8qB2eypGfPZ9Ya80z70IDf0D7AjwKdHMwoFkBHPJNXwAoOT57lDKVA/vxYu1b32 euOxHOz+Hwd6QPd4Gm4yRFoO247BNQLmsaUapJLmkfyucAt4r1P1GcKX3/rHnC4+KTz7 uj1qW/bTulQBwzHCzlEy/NeKNespPZdlkNmdjg+OyGjjdZfycyc3kzSsGS1J0KpnaMR+ REQgeiR9QBcdtR2plWq9+O74zC57Bxv29V9M/+4grN4tS8xXFDBvcqqfnfVJBHVlYnh8 Tq4w== X-Gm-Message-State: AGi0Puak6NXnNigpEodyYNbXiRw6S4kIiEnaa3URsLeB6ZexdytohX6M x6U+tJRU0CNsG3Z6iHLoDtY= X-Google-Smtp-Source: APiQypKhv5FpIxzg1qAe149DwHEhWqCe+v9xO+HbccsxzWB6gnxdWEuZvYLqbYIIA69d8umrxcekoA== X-Received: by 2002:a1c:197:: with SMTP id 145mr4648308wmb.42.1586949955700; Wed, 15 Apr 2020 04:25:55 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:7a8e:ed70:5c52:ea3]) by smtp.gmail.com with ESMTPSA id c190sm22561214wme.10.2020.04.15.04.25.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 04:25:54 -0700 (PDT) Message-ID: <44ecd81e7176d7f98a2571f7e1c83e793fc15b4c.camel@debian.org> From: Luca Boccassi To: Ferruh Yigit , Thomas Monjalon , Alexander Kozyrev , Kevin Traynor Cc: dev@dpdk.org, rasland@mellanox.com, matan@mellanox.com, viacheslavo@mellanox.com, stable@dpdk.org, David Marchand Date: Wed, 15 Apr 2020 12:25:54 +0100 In-Reply-To: <1c29d98a-68c9-11f6-f4dc-539211ebc185@intel.com> References: <1585851108-485-1-git-send-email-akozyrev@mellanox.com> <1586471033-17130-2-git-send-email-akozyrev@mellanox.com> <9093c839-5655-6583-cc10-471a51ecccca@intel.com> <3469922.C4sosBPzcN@thomas> <1c29d98a-68c9-11f6-f4dc-539211ebc185@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 1/3] net/mlx5: add a devarg to specify MPRQ stride size 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, 2020-04-15 at 12:01 +0100, Ferruh Yigit wrote: > On 4/14/2020 1:52 PM, Thomas Monjalon wrote: > > 14/04/2020 13:42, Ferruh Yigit: > > > On 4/9/2020 11:23 PM, Alexander Kozyrev wrote: > > > > Define a device parameter to configure log 2 of a stride size for M= PRQ > > > > - mprq_log_stride_size. User is able to specify a stride size in a = range > > > > allowed by an underlying hardware. The default stride size is defin= ed as > > > > 2048 bytes to encompass most commonly used packet sizes in the Inte= rnet > > > > (MTU 1518 and less) and will be used in case a maximum configured p= acket > > > > size cannot fit into the largest possible stride size. Otherwise a > > > > stride size is set to a large enough value to encompass a whole pac= ket. > > > >=20 > > > > Cc: stable@dpdk.org > > >=20 > > > Hi Alexander, > > >=20 > > > This is a new feature, and you are asking it for to be backported to = the stable > > > trees. > > >=20 > > > There is no question on getting the fixes to the stable tree, but for > > > backporting features I would like to get the comment of the stable tr= ee > > > maintainers first before merging the series. > >=20 > > As far as I know, there is a fix hidden in this series, > > for the case of jumbo frames. > > In my understanding, jumbo frames cannot be fixed without a new option. > > I agree it's tricky deciding what is the limit with backports. > >=20 >=20 > I missed the fix bit, so if there is no objection from stable tree mainta= iners I > will continue with the set keeping the stable tag. Given it's confined to a single PMD it's fine by me, provided that: 1) Backward compatibility is maintained 2) Forward compatibility is maintained (eg: going 19.11.x to 20.02 should still work and not cause any errors) --=20 Luca Boccassi