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.8 required=3.0 tests=BAYES_00, 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 8E614C433FE for ; Tue, 8 Dec 2020 06:23:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 418F223A63 for ; Tue, 8 Dec 2020 06:23:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725910AbgLHGXD (ORCPT ); Tue, 8 Dec 2020 01:23:03 -0500 Received: from mx2.suse.de ([195.135.220.15]:32806 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbgLHGXD (ORCPT ); Tue, 8 Dec 2020 01:23:03 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B9515AD7C; Tue, 8 Dec 2020 06:22:21 +0000 (UTC) Received: by lion.mk-sys.cz (Postfix, from userid 1000) id 1131C6078E; Tue, 8 Dec 2020 07:22:20 +0100 (CET) Date: Tue, 8 Dec 2020 07:22:20 +0100 From: Michal Kubecek To: Vinicius Costa Gomes Cc: Jakub Kicinski , netdev@vger.kernel.org, jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, m-karicheri2@ti.com, vladimir.oltean@nxp.com, Jose.Abreu@synopsys.com, po.liu@nxp.com, intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com Subject: Re: [PATCH net-next v1 1/9] ethtool: Add support for configuring frame preemption Message-ID: <20201208062220.3xrhdo47lgpyttfi@lion.mk-sys.cz> References: <20201202045325.3254757-1-vinicius.gomes@intel.com> <20201202045325.3254757-2-vinicius.gomes@intel.com> <20201205094325.790b187f@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> <87eek11d23.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eek11d23.fsf@intel.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Dec 07, 2020 at 02:11:48PM -0800, Vinicius Costa Gomes wrote: > Jakub Kicinski writes: > >> + * @min_frag_size_mult: Minimum size for all non-final fragment size, > >> + * expressed in terms of X in '(1 + X)*64 + 4' > > > > Is this way of expressing the min frag size from the standard? > > > > The standard has this: "A 2-bit integer value indicating, in units of 64 > octets, the minimum number of octets over 64 octets required in > non-final fragments by the receiver" from IEEE 802.3br-2016, Table > 79-7a. Can we be sure that newer version of the standard cannot change this, e.g. come with a finer granularity? Perhaps it would be safer to express the size in bytes in the userspace API and translate to this internal representation in common ethtool code. Also, please don't forget to update Documentation/networking/ethtool-netlink.rst Michal From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Kubecek Date: Tue, 8 Dec 2020 07:22:20 +0100 Subject: [Intel-wired-lan] [PATCH net-next v1 1/9] ethtool: Add support for configuring frame preemption In-Reply-To: <87eek11d23.fsf@intel.com> References: <20201202045325.3254757-1-vinicius.gomes@intel.com> <20201202045325.3254757-2-vinicius.gomes@intel.com> <20201205094325.790b187f@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> <87eek11d23.fsf@intel.com> Message-ID: <20201208062220.3xrhdo47lgpyttfi@lion.mk-sys.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Mon, Dec 07, 2020 at 02:11:48PM -0800, Vinicius Costa Gomes wrote: > Jakub Kicinski writes: > >> + * @min_frag_size_mult: Minimum size for all non-final fragment size, > >> + * expressed in terms of X in '(1 + X)*64 + 4' > > > > Is this way of expressing the min frag size from the standard? > > > > The standard has this: "A 2-bit integer value indicating, in units of 64 > octets, the minimum number of octets over 64 octets required in > non-final fragments by the receiver" from IEEE 802.3br-2016, Table > 79-7a. Can we be sure that newer version of the standard cannot change this, e.g. come with a finer granularity? Perhaps it would be safer to express the size in bytes in the userspace API and translate to this internal representation in common ethtool code. Also, please don't forget to update Documentation/networking/ethtool-netlink.rst Michal