From: Vladimir Oltean <olteanv@gmail.com>
To: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH iwl-next 5/9] igc: Add support to set MAC Merge data via ethtool
Date: Mon, 23 Dec 2024 23:43:43 +0200 [thread overview]
Message-ID: <20241223214343.dbmhbj7cr7pfbeub@skbuf> (raw)
In-Reply-To: <ef07ba7e-eb61-495b-8abc-a46d675302d4@linux.intel.com>
Hi Faizal,
On Mon, Dec 23, 2024 at 05:23:27PM +0800, Abdul Rahim, Faizal wrote:
> To recap:
>
> Standard range: 60, 124, 188, 252 (without mCRC).
> i226 range: 64, 128, 192, 256 (without mCRC).
>
> The current IGC_TX_MIN_FRAG_SIZE is incorrectly set to 68 due to our
> misinterpretation of the i226 documentation:
> "The minimum size for non-final preempted fragments is 64 * (1 + MIN_FRAG) +
> 4 (mCRC)."
>
> The calculation above is for the fragment size on the wire, including mCRC.
> For the TX preemption point and pure fragment size, mCRC should not be
> included, as confirmed by the hardware owner.
>
> On RX, i226 can handle any size, even the standard minimum of 60 octets
> (without mCRC).
>
> What would be ideal for i226:
> Min frag user set 60:64 → Multiplier = 0.
> Min frag user set 65:128 → Multiplier = 1.
> (And so on)
>
> To make this work and reuse the existing code, we’d need to tweak these two
> functions:
> ethtool_mm_frag_size_add_to_min(val_min, xxx)
> ethtool_mm_frag_size_min_to_add(xx)
>
> With the current code, if I pass 64 octets as val_min to
> ethtool_mm_frag_size_add_to_min(), it returns error.
>
> Proposed modification:
> Add a new parameter to ethtool_mm_frag_size_min_to_add() - maybe let's call
> it dev_min_tx_frag_len.
>
> Set dev_min_tx_frag_len = 64 for i226, 60 for other drivers.
> This field will be used to:
> (1) modify the calculation in ethtool_mm_frag_size_min_to_add()
> (2) as a warning prompt to user when the value is not standard, done in
> ethtool_mm_frag_size_add_to_min()
>
> I was thinking (1) would modify the existing:
> u32 ethtool_mm_frag_size_add_to_min(u32 val_add)
> {
> return (ETH_ZLEN + ETH_FCS_LEN) * (1 + val_add) - ETH_FCS_LEN;
> }
>
> To something like:
> u32 ethtool_mm_frag_size_add_to_min(u32 val_add, u32 dev_min_tx_frag_len)
> {
> return dev_min_tx_frag_len + (val_add * 64);
> }
>
> So this will yield:
> Standard range (dev_min_tx_frag_len = 60): 60, 124, 188, 252
> i226 range (dev_min_tx_frag_len = 64): 64, 128, 192, 256
>
> But what's not so nice is, the rest of other drivers have to set this new
> param when calling ethtool_mm_frag_size_add_to_min().
>
> Is something like this okay ? I'm open to better suggestion.
I'm taking a break probably for the rest of the year, and spending time
for the Christmas holidays mostly off lists.
I didn't look through all your replies. Just regarding the one quoted
above: just don't use the ethtool_mm_frag_size_add_to_min() and
ethtool_mm_frag_size_min_to_add() helpers if they aren't useful as-is.
They are designed for a standardized NIC implementation. They are opt-in
from driver code for a reason.
next prev parent reply other threads:[~2024-12-23 21:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 6:47 [PATCH iwl-next 0/9] igc: Add support for Frame Preemption feature in IGC Faizal Rahim
2024-12-16 6:47 ` [PATCH iwl-next 1/9] igc: Rename xdp_get_tx_ring() for non-xdp usage Faizal Rahim
2024-12-16 6:47 ` [PATCH iwl-next 2/9] igc: Optimize the TX packet buffer utilization Faizal Rahim
2024-12-16 6:47 ` [PATCH iwl-next 3/9] igc: Set the RX packet buffer size for TSN mode Faizal Rahim
2024-12-16 6:47 ` [PATCH iwl-next 4/9] igc: Add support for receiving frames with all zeroes address Faizal Rahim
2024-12-16 17:26 ` Vladimir Oltean
2024-12-16 6:47 ` [PATCH iwl-next 5/9] igc: Add support to set MAC Merge data via ethtool Faizal Rahim
2024-12-16 18:13 ` Vladimir Oltean
2024-12-17 0:39 ` Vladimir Oltean
2024-12-23 9:23 ` Abdul Rahim, Faizal
2024-12-23 21:43 ` Vladimir Oltean [this message]
2024-12-16 6:47 ` [PATCH iwl-next 6/9] igc: Add support for frame preemption verification Faizal Rahim
2024-12-17 0:22 ` Vladimir Oltean
2024-12-17 8:46 ` Vladimir Oltean
2024-12-17 9:47 ` Abdul Rahim, Faizal
2024-12-17 12:09 ` Furong Xu
2024-12-19 7:24 ` Choong Yong Liang
2024-12-23 9:32 ` Abdul Rahim, Faizal
2024-12-16 6:47 ` [PATCH iwl-next 7/9] igc: Add support for preemptible traffic class in taprio Faizal Rahim
2024-12-16 6:47 ` [PATCH iwl-next 8/9] igc: Add support to get MAC Merge data via ethtool Faizal Rahim
2024-12-17 0:35 ` Vladimir Oltean
2024-12-23 9:39 ` Abdul Rahim, Faizal
2024-12-16 6:47 ` [PATCH iwl-next 9/9] igc: Add support to get frame preemption statistics " Faizal Rahim
2024-12-16 16:05 ` Vladimir Oltean
2024-12-23 9:52 ` Abdul Rahim, Faizal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241223214343.dbmhbj7cr7pfbeub@skbuf \
--to=olteanv@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=faizal.abdul.rahim@linux.intel.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=vinicius.gomes@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox