All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Kurt Kanzenbach <kurt@linutronix.de>,
	Vladimir Oltean <vladimir.oltean@nxp.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>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Simon Horman <horms@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Furong Xu <0x1207@gmail.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Serge Semin <fancer.lancer@gmail.com>,
	Xiaolei Wang <xiaolei.wang@windriver.com>,
	Suraj Jaiswal <quic_jsuraj@quicinc.com>,
	Kory Maincent <kory.maincent@bootlin.com>,
	Gal Pressman <gal@nvidia.com>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Andrew Halaney <ahalaney@redhat.com>,
	Choong Yong Liang <yong.liang.choong@linux.intel.com>,
	Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC
Date: Fri, 14 Feb 2025 12:50:04 +0800	[thread overview]
Message-ID: <e5c5d7ed-9f47-4af1-aee4-4632099bd546@linux.intel.com> (raw)
In-Reply-To: <b7740709-6b4a-4f44-b4d7-e265bb823aca@linux.intel.com>



On 14/2/2025 12:20 pm, Abdul Rahim, Faizal wrote:
> 
> 
> On 14/2/2025 3:12 am, Kurt Kanzenbach wrote:
>> On Thu Feb 13 2025, Vladimir Oltean wrote:
>>> So, confusingly to me, it seems like one operating mode is fundamentally
>>> different from the other, and something will have to change if both will
>>> be made to behave the same. What will change? You say mqprio will behave
>>> like taprio, but I think if anything, mqprio is the one which does the
>>> right thing, in igc_tsn_tx_arb(), and taprio seems to use the default Tx
>>> arbitration scheme?
>>
>> Correct. taprio is using the default scheme. mqprio configures it to
>> what ever the user provided (in igc_tsn_tx_arb()).
>>
>>> I don't think I'm on the same page as you guys, because to me, it is
>>> just odd that the P traffic classes would be the first ones with
>>> mqprio, but the last ones with taprio.
>>
>> I think we are on the same page here. At the end both have to behave the
>> same. Either by using igc_tsn_tx_arb() for taprio too or only using the
>> default scheme for both (and thereby keeping broken_mqprio). Whatever
>> Faizal implements I'll match the behavior with mqprio.
>>
> 
> Hi Kurt & Vladimir,
> 
> After reading Vladimir's reply on tc, hw queue, and socket priority mapping 
> for both taprio and mqprio, I agree they should follow the same priority 
> scheme for consistency—both in code and command usage (i.e., taprio, 
> mqprio, and fpe in both configurations). Since igc_tsn_tx_arb() ensures a 
> standard mapping of tc, socket priority, and hardware queue priority, I'll 
> enable taprio to use igc_tsn_tx_arb() in a separate patch submission.
> 
> I'll split the changes based on Vladimir's suggestion.
> 
> First part - ethtool-mm related:
> igc: Add support to get frame preemption statistics via ethtool
> igc: Add support to get MAC Merge data via ethtool
> igc: Add support to set tx-min-frag-size
> igc: Add support for frame preemption verification
> igc: Set the RX packet buffer size for TSN mode
> igc: Optimize TX packet buffer utilization
> igc: Rename xdp_get_tx_ring() for non-XDP usage
> net: ethtool: mm: Extract stmmac verification logic into a common library
> 
> Second part:
> igc: Add support for preemptible traffic class in taprio and mqprio
> igc: Use igc_tsn_tx_arb() for taprio queue priority scheme
> igc: Kurt's patch on mqprio to use normal TSN Tx mode
> 
> Kurt can keep igc_tsn_tx_arb() for his mqprio patch, so preemptible tc 
> should work the same for both taprio and mqprio.
> 
> I'm suggesting to include Kurt's patch in the second part since there's 
> some dependency and potential code conflict, even though it mixes different 
> functional changes in the same series.

I forgot that the second part patch:
igc: Add support for preemptible traffic class in taprio and mqprio

depends on the first part ethtool-mm, which would delay Kurt's patch.

So Kurt, if you'd prefer to submit yours first, that's okay too.




WARNING: multiple messages have this Message-ID (diff)
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Kurt Kanzenbach <kurt@linutronix.de>,
	Vladimir Oltean <vladimir.oltean@nxp.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>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Simon Horman <horms@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Furong Xu <0x1207@gmail.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Serge Semin <fancer.lancer@gmail.com>,
	Xiaolei Wang <xiaolei.wang@windriver.com>,
	Suraj Jaiswal <quic_jsuraj@quicinc.com>,
	Kory Maincent <kory.maincent@bootlin.com>,
	Gal Pressman <gal@nvidia.com>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Andrew Halaney <ahalaney@redhat.com>,
	Choong Yong Liang <yong.liang.choong@linux.intel.com>,
	Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC
Date: Fri, 14 Feb 2025 12:50:04 +0800	[thread overview]
Message-ID: <e5c5d7ed-9f47-4af1-aee4-4632099bd546@linux.intel.com> (raw)
In-Reply-To: <b7740709-6b4a-4f44-b4d7-e265bb823aca@linux.intel.com>



On 14/2/2025 12:20 pm, Abdul Rahim, Faizal wrote:
> 
> 
> On 14/2/2025 3:12 am, Kurt Kanzenbach wrote:
>> On Thu Feb 13 2025, Vladimir Oltean wrote:
>>> So, confusingly to me, it seems like one operating mode is fundamentally
>>> different from the other, and something will have to change if both will
>>> be made to behave the same. What will change? You say mqprio will behave
>>> like taprio, but I think if anything, mqprio is the one which does the
>>> right thing, in igc_tsn_tx_arb(), and taprio seems to use the default Tx
>>> arbitration scheme?
>>
>> Correct. taprio is using the default scheme. mqprio configures it to
>> what ever the user provided (in igc_tsn_tx_arb()).
>>
>>> I don't think I'm on the same page as you guys, because to me, it is
>>> just odd that the P traffic classes would be the first ones with
>>> mqprio, but the last ones with taprio.
>>
>> I think we are on the same page here. At the end both have to behave the
>> same. Either by using igc_tsn_tx_arb() for taprio too or only using the
>> default scheme for both (and thereby keeping broken_mqprio). Whatever
>> Faizal implements I'll match the behavior with mqprio.
>>
> 
> Hi Kurt & Vladimir,
> 
> After reading Vladimir's reply on tc, hw queue, and socket priority mapping 
> for both taprio and mqprio, I agree they should follow the same priority 
> scheme for consistency—both in code and command usage (i.e., taprio, 
> mqprio, and fpe in both configurations). Since igc_tsn_tx_arb() ensures a 
> standard mapping of tc, socket priority, and hardware queue priority, I'll 
> enable taprio to use igc_tsn_tx_arb() in a separate patch submission.
> 
> I'll split the changes based on Vladimir's suggestion.
> 
> First part - ethtool-mm related:
> igc: Add support to get frame preemption statistics via ethtool
> igc: Add support to get MAC Merge data via ethtool
> igc: Add support to set tx-min-frag-size
> igc: Add support for frame preemption verification
> igc: Set the RX packet buffer size for TSN mode
> igc: Optimize TX packet buffer utilization
> igc: Rename xdp_get_tx_ring() for non-XDP usage
> net: ethtool: mm: Extract stmmac verification logic into a common library
> 
> Second part:
> igc: Add support for preemptible traffic class in taprio and mqprio
> igc: Use igc_tsn_tx_arb() for taprio queue priority scheme
> igc: Kurt's patch on mqprio to use normal TSN Tx mode
> 
> Kurt can keep igc_tsn_tx_arb() for his mqprio patch, so preemptible tc 
> should work the same for both taprio and mqprio.
> 
> I'm suggesting to include Kurt's patch in the second part since there's 
> some dependency and potential code conflict, even though it mixes different 
> functional changes in the same series.

I forgot that the second part patch:
igc: Add support for preemptible traffic class in taprio and mqprio

depends on the first part ethtool-mm, which would delay Kurt's patch.

So Kurt, if you'd prefer to submit yours first, that's okay too.




  reply	other threads:[~2025-02-14  4:50 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10  7:01 [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC Faizal Rahim
2025-02-10  7:01 ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:01 ` [PATCH iwl-next v4 1/9] net: ethtool: mm: extract stmmac verification logic into common library Faizal Rahim
2025-02-10  7:01   ` [Intel-wired-lan] " Faizal Rahim
2025-02-12 23:09   ` Vladimir Oltean
2025-02-12 23:09     ` [Intel-wired-lan] " Vladimir Oltean
2025-02-10  7:02 ` [PATCH iwl-next v4 2/9] igc: Rename xdp_get_tx_ring() for non-xdp usage Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 3/9] igc: Optimize the TX packet buffer utilization Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 4/9] igc: Set the RX packet buffer size for TSN mode Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 5/9] igc: Add support for frame preemption verification Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-17 11:31   ` Simon Horman
2025-02-17 11:31     ` [Intel-wired-lan] " Simon Horman
2025-02-19  1:48     ` Abdul Rahim, Faizal
2025-02-19  1:48       ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-10  7:02 ` [PATCH iwl-next v4 6/9] igc: Add support to set tx-min-frag-size Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 7/9] igc: Add support for preemptible traffic class in taprio Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 8/9] igc: Add support to get MAC Merge data via ethtool Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-10  7:02 ` [PATCH iwl-next v4 9/9] igc: Add support to get frame preemption statistics " Faizal Rahim
2025-02-10  7:02   ` [Intel-wired-lan] " Faizal Rahim
2025-02-12 21:54   ` Vladimir Oltean
2025-02-12 21:54     ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13  5:42     ` Abdul Rahim, Faizal
2025-02-13  5:42       ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-12 22:01 ` [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC Vladimir Oltean
2025-02-12 22:01   ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13  6:12   ` Abdul Rahim, Faizal
2025-02-13  6:12     ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-13  9:00     ` Vladimir Oltean
2025-02-13  9:00       ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13 11:06       ` Vladimir Oltean
2025-02-13 11:06         ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13 12:01     ` Kurt Kanzenbach
2025-02-13 12:01       ` [Intel-wired-lan] " Kurt Kanzenbach
2025-02-13 12:54       ` Abdul Rahim, Faizal
2025-02-13 12:54         ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-13 13:00         ` Vladimir Oltean
2025-02-13 13:00           ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13 13:54           ` Abdul Rahim, Faizal
2025-02-13 13:54             ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-13 14:12             ` Kurt Kanzenbach
2025-02-13 14:12               ` [Intel-wired-lan] " Kurt Kanzenbach
2025-02-13 18:46               ` Vladimir Oltean
2025-02-13 18:46                 ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13 19:12                 ` Kurt Kanzenbach
2025-02-13 19:12                   ` [Intel-wired-lan] " Kurt Kanzenbach
2025-02-14  4:20                   ` Abdul Rahim, Faizal
2025-02-14  4:20                     ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-14  4:50                     ` Abdul Rahim, Faizal [this message]
2025-02-14  4:50                       ` Abdul Rahim, Faizal
2025-02-14  8:56                     ` Kurt Kanzenbach
2025-02-14  8:56                       ` [Intel-wired-lan] " Kurt Kanzenbach
2025-02-14  9:43                       ` Abdul Rahim, Faizal
2025-02-14  9:43                         ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-14 10:22                         ` Vladimir Oltean
2025-02-14 10:22                           ` [Intel-wired-lan] " Vladimir Oltean
2025-02-14 11:20                           ` Abdul Rahim, Faizal
2025-02-14 11:20                             ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-02-14 11:38                             ` Vladimir Oltean
2025-02-14 11:38                               ` [Intel-wired-lan] " Vladimir Oltean
2025-02-13  8:59   ` Loktionov, Aleksandr
2025-02-13  8:59     ` Loktionov, Aleksandr
2025-02-20  3:08     ` 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=e5c5d7ed-9f47-4af1-aee4-4632099bd546@linux.intel.com \
    --to=faizal.abdul.rahim@linux.intel.com \
    --cc=0x1207@gmail.com \
    --cc=ahalaney@redhat.com \
    --cc=alexandre.torgue@foss.st.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=fancer.lancer@gmail.com \
    --cc=gal@nvidia.com \
    --cc=hawk@kernel.org \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesper.nilsson@axis.com \
    --cc=john.fastabend@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=quic_jsuraj@quicinc.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=vinicius.gomes@intel.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=xiaolei.wang@windriver.com \
    --cc=yong.liang.choong@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.