Message ID | 20230220122343.1156614-1-vladimir.oltean@nxp.com (mailing list archive) |
---|---|
Headers | show |
Series | Add tc-mqprio and tc-taprio support for preemptible traffic classes | expand |
On Mon, 20 Feb 2023 14:23:30 +0200 Vladimir Oltean wrote: > Some patches should have maybe belonged to separate series, leaving here > only patches 07/13 - 13/13, for ease of review. That may be true, > however due to a perceived lack of time to wait for the prerequisite > cleanup to be merged, here they are all together. net-next is already closed, sorry :(
On Mon, Feb 20, 2023 at 04:55:02PM -0800, Jakub Kicinski wrote: > On Mon, 20 Feb 2023 14:23:30 +0200 Vladimir Oltean wrote: > > Some patches should have maybe belonged to separate series, leaving here > > only patches 07/13 - 13/13, for ease of review. That may be true, > > however due to a perceived lack of time to wait for the prerequisite > > cleanup to be merged, here they are all together. > > net-next is already closed, sorry :( Can you take patch 1, or would I have to resend that separately to "net" after $n days?
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Mon, 20 Feb 2023 14:23:30 +0200 you wrote: > The last RFC in August 2022 contained a proposal for the UAPI of both > TSN standards which together form Frame Preemption (802.1Q and 802.3): > https://lore.kernel.org/netdev/20220816222920.1952936-1-vladimir.oltean@nxp.com/ > > It wasn't clear at the time whether the 802.1Q portion of Frame Preemption > should be exposed via the tc qdisc (mqprio, taprio) or via some other > layer (perhaps also ethtool like the 802.3 portion, or dcbnl), even > though the options were discussed extensively, with pros and cons: > https://lore.kernel.org/netdev/20220816222920.1952936-3-vladimir.oltean@nxp.com/ > > [...] Here is the summary with links: - [v3,net-next,01/13] net: ethtool: fix __ethtool_dev_mm_supported() implementation https://git.kernel.org/netdev/net-next/c/a00da30c052f - [v3,net-next,02/13] net: ethtool: create and export ethtool_dev_mm_supported() (no matching commit) - [v3,net-next,03/13] net/sched: mqprio: simplify handling of nlattr portion of TCA_OPTIONS (no matching commit) - [v3,net-next,04/13] net/sched: mqprio: add extack to mqprio_parse_nlattr() (no matching commit) - [v3,net-next,05/13] net/sched: mqprio: add an extack message to mqprio_parse_opt() (no matching commit) - [v3,net-next,06/13] net/sched: pass netlink extack to mqprio and taprio offload (no matching commit) - [v3,net-next,07/13] net/sched: mqprio: allow per-TC user input of FP adminStatus (no matching commit) - [v3,net-next,08/13] net/sched: taprio: allow per-TC user input of FP adminStatus (no matching commit) - [v3,net-next,09/13] net: enetc: rename "mqprio" to "qopt" (no matching commit) - [v3,net-next,10/13] net: mscc: ocelot: add support for mqprio offload (no matching commit) - [v3,net-next,11/13] net: dsa: felix: act upon the mqprio qopt in taprio offload (no matching commit) - [v3,net-next,12/13] net: mscc: ocelot: add support for preemptible traffic classes (no matching commit) - [v3,net-next,13/13] net: enetc: add support for preemptible traffic classes (no matching commit) You are awesome, thank you!
On Mon, Feb 20, 2023 at 02:23:30PM +0200, Vladimir Oltean wrote: > This series proposes that we use the Qdisc layer, through separate > (albeit very similar) UAPI in mqprio and taprio, and that both these > Qdiscs pass the information down to the offloading device driver through > the common mqprio offload structure (which taprio also passes). Are there any comments before I resend this? So far I have no changes planned for v4.
On Sat, Mar 11, 2023 at 11:56:16PM +0200, Vladimir Oltean wrote: > On Mon, Feb 20, 2023 at 02:23:30PM +0200, Vladimir Oltean wrote: > > This series proposes that we use the Qdisc layer, through separate > > (albeit very similar) UAPI in mqprio and taprio, and that both these > > Qdiscs pass the information down to the offloading device driver through > > the common mqprio offload structure (which taprio also passes). > > Are there any comments before I resend this? So far I have no changes > planned for v4. FWIIW, I am now reviewing v3 - I missed that only the first patch was was applied when the message from patch bot arrived. So far I am up to patch 08/13 and nothing stands out so far. And I can just as easily review v4.
On Mon, Mar 13, 2023 at 04:00:53PM +0100, Simon Horman wrote: > On Sat, Mar 11, 2023 at 11:56:16PM +0200, Vladimir Oltean wrote: > > On Mon, Feb 20, 2023 at 02:23:30PM +0200, Vladimir Oltean wrote: > > > This series proposes that we use the Qdisc layer, through separate > > > (albeit very similar) UAPI in mqprio and taprio, and that both these > > > Qdiscs pass the information down to the offloading device driver through > > > the common mqprio offload structure (which taprio also passes). > > > > Are there any comments before I resend this? So far I have no changes > > planned for v4. > > FWIIW, I am now reviewing v3 - I missed that only the first patch was > was applied when the message from patch bot arrived. So far I > am up to patch 08/13 and nothing stands out so far. And I can just as > easily review v4. FWIIW, I completed my review. Reviewed-by: Simon Horman <simon.horman@corigine.com>