linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Rui Sousa <rui.sousa@nxp.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	UNGLinuxDriver@microchip.com,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Michael Walle <michael@walle.cc>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	Maxim Kochetkov <fido_max@inbox.ru>,
	Colin Foster <colin.foster@in-advantage.com>,
	Richie Pearn <richard.pearn@nxp.com>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	Vladimir Oltean <olteanv@gmail.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v4 net-next 0/8] Add tc-taprio support for queueMaxSDU
Date: Wed, 28 Sep 2022 12:51:56 +0300	[thread overview]
Message-ID: <20220928095204.2093716-1-vladimir.oltean@nxp.com> (raw)

Changes in v4:
- avoid bogus fall-through in the implementations of the tc_query_caps
  methods
- fix bogus patch splitting in hellcreek

v3 at:
https://patchwork.kernel.org/project/netdevbpf/cover/20220927234746.1823648-1-vladimir.oltean@nxp.com/

Changes in v3:
- at Jakub's suggestion, implement a TC_QUERY_CAPS functionality in
  ndo_setup_tc through which drivers can opt into features, rather than
  out of them
- consequently, drop patches to am65-cpsw, stmmac, igc, tsnep, lan966x

Non-changes in v3:
- still not using the nla_policy to limit the range for the tc index
- still not using the NL_SET_ERR_ATTR_MISS() helper to report a missing
  tc entry index attribute
As discussed here, this would actually make things less user friendly,
until iproute2 gains support for policy tables and for meaningfully
parsing the offset to the bad attribute, something which I've no idea
how to do.
https://patchwork.kernel.org/project/netdevbpf/patch/20220923163310.3192733-2-vladimir.oltean@nxp.com/

v2 at:
https://patchwork.kernel.org/project/netdevbpf/list/?series=679954&state=*

Changes in v2:
- precompute the max_frm_len using dev->hard_header_len, so that the
  fast path can directly check against skb->len
- add the newly added lan966x taprio offload to the list of drivers
  which must reject the new option
- add some enetc cleanup patches from
  https://patchwork.kernel.org/project/netdevbpf/patch/20220921144349.1529150-2-vladimir.oltean@nxp.com/
- get rid of some taprio cleanup patches which were merged separately
  via https://patchwork.kernel.org/project/netdevbpf/cover/20220915105046.2404072-1-vladimir.oltean@nxp.com/
- make enetc_vf.ko compile by excluding the taprio offload code:
  https://patchwork.kernel.org/project/netdevbpf/patch/20220916133209.3351399-2-vladimir.oltean@nxp.com/

v1 at:
https://patchwork.kernel.org/project/netdevbpf/cover/20220914153303.1792444-1-vladimir.oltean@nxp.com/



The tc-taprio offload mode supported by the Felix DSA driver has
limitations surrounding its guard bands.

The initial discussion was at:
https://lore.kernel.org/netdev/c7618025da6723418c56a54fe4683bd7@walle.cc/

with the latest status being that we now have a vsc9959_tas_guard_bands_update()
method which makes a best-guess attempt at how much useful space to
reserve for packet scheduling in a taprio interval, and how much to
reserve for guard bands.

IEEE 802.1Q actually does offer a tunable variable (queueMaxSDU) which
can determine the max MTU supported per traffic class. In turn we can
determine the size we need for the guard bands, depending on the
queueMaxSDU. This way we can make the guard band of small taprio
intervals smaller than one full MTU worth of transmission time, if we
know that said traffic class will transport only smaller packets.

As discussed with Gerhard Engleder, the queueMaxSDU may also be useful
in limiting the latency on an endpoint, if some of the TX queues are
outside of the control of the Linux driver.
https://patchwork.kernel.org/project/netdevbpf/patch/20220914153303.1792444-11-vladimir.oltean@nxp.com/

Allow input of queueMaxSDU through netlink into tc-taprio, offload it to
the hardware I have access to (LS1028A), and (implicitly) deny
non-default values to everyone else. Kurt Kanzenbach has also kindly
tested and shared a patch to offload this to hellcreek.

Kurt Kanzenbach (1):
  net: dsa: hellcreek: Offload per-tc max SDU from tc-taprio

Vladimir Oltean (7):
  net/sched: query offload capabilities through ndo_setup_tc()
  net/sched: taprio: allow user input of per-tc max SDU
  net: dsa: felix: offload per-tc max SDU from tc-taprio
  net: dsa: hellcreek: refactor hellcreek_port_setup_tc() to use
    switch/case
  net: enetc: cache accesses to &priv->si->hw
  net: enetc: use common naming scheme for PTGCR and PTGCAPR registers
  net: enetc: offload per-tc max SDU from tc-taprio

 drivers/net/dsa/hirschmann/hellcreek.c        |  96 +++++++++--
 drivers/net/dsa/hirschmann/hellcreek.h        |   7 +
 drivers/net/dsa/ocelot/felix_vsc9959.c        |  37 ++++-
 drivers/net/ethernet/freescale/enetc/enetc.c  |  28 ++--
 drivers/net/ethernet/freescale/enetc/enetc.h  |  14 +-
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  10 +-
 .../net/ethernet/freescale/enetc/enetc_pf.c   |  27 +++-
 .../net/ethernet/freescale/enetc/enetc_qos.c  |  94 ++++++-----
 include/linux/netdevice.h                     |   1 +
 include/net/pkt_sched.h                       |  10 ++
 include/net/sch_generic.h                     |   3 +
 include/uapi/linux/pkt_sched.h                |  11 ++
 net/sched/sch_api.c                           |  17 ++
 net/sched/sch_taprio.c                        | 152 +++++++++++++++++-
 14 files changed, 433 insertions(+), 74 deletions(-)

-- 
2.34.1


             reply	other threads:[~2022-09-28  9:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28  9:51 Vladimir Oltean [this message]
2022-09-28  9:51 ` [PATCH v4 net-next 1/8] net/sched: query offload capabilities through ndo_setup_tc() Vladimir Oltean
2022-09-28  9:51 ` [PATCH v4 net-next 2/8] net/sched: taprio: allow user input of per-tc max SDU Vladimir Oltean
2022-09-28  9:51 ` [PATCH v4 net-next 3/8] net: dsa: felix: offload per-tc max SDU from tc-taprio Vladimir Oltean
2022-09-28  9:52 ` [PATCH v4 net-next 4/8] net: dsa: hellcreek: refactor hellcreek_port_setup_tc() to use switch/case Vladimir Oltean
2022-09-28 13:00   ` Kurt Kanzenbach
2022-09-28  9:52 ` [PATCH v4 net-next 5/8] net: dsa: hellcreek: Offload per-tc max SDU from tc-taprio Vladimir Oltean
2022-09-28  9:52 ` [PATCH v4 net-next 6/8] net: enetc: cache accesses to &priv->si->hw Vladimir Oltean
2022-09-28  9:52 ` [PATCH v4 net-next 7/8] net: enetc: use common naming scheme for PTGCR and PTGCAPR registers Vladimir Oltean
2022-09-28  9:52 ` [PATCH v4 net-next 8/8] net: enetc: offload per-tc max SDU from tc-taprio Vladimir Oltean
2022-09-30  2:21 ` [PATCH v4 net-next 0/8] Add tc-taprio support for queueMaxSDU patchwork-bot+netdevbpf

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=20220928095204.2093716-1-vladimir.oltean@nxp.com \
    --to=vladimir.oltean@nxp.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=colin.foster@in-advantage.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=fido_max@inbox.ru \
    --cc=horatiu.vultur@microchip.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=richard.pearn@nxp.com \
    --cc=rui.sousa@nxp.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vivien.didelot@gmail.com \
    --cc=xiaoliang.yang_1@nxp.com \
    --cc=xiyou.wangcong@gmail.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;
as well as URLs for NNTP newsgroup(s).