| Message ID | 20220914153303.1792444-1-vladimir.oltean@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add tc-taprio support for queueMaxSDU | expand |
Vladimir Oltean <vladimir.oltean@nxp.com> writes: > Michael and Xiaoliang will probably be aware that 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. > > Allow input of queueMaxSDU through netlink into tc-taprio, offload it to > the hardware I have access to (LS1028A), and deny non-default values to > everyone else. > > First 3 patches are some cleanups I made while figuring out what exactly > gets called for taprio software mode, and what gets called for offload > mode. > > Vladimir Oltean (13): > net/sched: taprio: remove redundant FULL_OFFLOAD_IS_ENABLED check in > taprio_enqueue > net/sched: taprio: stop going through private ops for dequeue and peek > net/sched: taprio: add extack messages in taprio_init Indeed. I think the first three patches can be in a separate series. > net/sched: taprio: allow user input of per-tc max SDU > net: dsa: felix: offload per-tc max SDU from tc-taprio > net: enetc: cache accesses to &priv->si->hw > net: enetc: offload per-tc max SDU from tc-taprio > net: dsa: hellcreek: deny tc-taprio changes to per-tc max SDU > net: dsa: sja1105: deny tc-taprio changes to per-tc max SDU > tsnep: deny tc-taprio changes to per-tc max SDU > igc: deny tc-taprio changes to per-tc max SDU > net: stmmac: deny tc-taprio changes to per-tc max SDU > net: am65-cpsw: deny tc-taprio changes to per-tc max SDU > > drivers/net/dsa/hirschmann/hellcreek.c | 5 + > drivers/net/dsa/ocelot/felix_vsc9959.c | 20 +- > drivers/net/dsa/sja1105/sja1105_tas.c | 6 +- > drivers/net/ethernet/engleder/tsnep_tc.c | 6 +- > drivers/net/ethernet/freescale/enetc/enetc.c | 28 ++- > drivers/net/ethernet/freescale/enetc/enetc.h | 12 +- > .../net/ethernet/freescale/enetc/enetc_pf.c | 25 ++- > .../net/ethernet/freescale/enetc/enetc_qos.c | 70 +++---- > drivers/net/ethernet/intel/igc/igc_main.c | 6 +- > .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 6 +- > drivers/net/ethernet/ti/am65-cpsw-qos.c | 6 +- > include/net/pkt_sched.h | 1 + > include/uapi/linux/pkt_sched.h | 11 + > net/sched/sch_taprio.c | 194 +++++++++++++----- > 14 files changed, 283 insertions(+), 113 deletions(-) > > -- > 2.34.1 > Cheers,
Michael and Xiaoliang will probably be aware that 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. Allow input of queueMaxSDU through netlink into tc-taprio, offload it to the hardware I have access to (LS1028A), and deny non-default values to everyone else. First 3 patches are some cleanups I made while figuring out what exactly gets called for taprio software mode, and what gets called for offload mode. Vladimir Oltean (13): net/sched: taprio: remove redundant FULL_OFFLOAD_IS_ENABLED check in taprio_enqueue net/sched: taprio: stop going through private ops for dequeue and peek net/sched: taprio: add extack messages in taprio_init net/sched: taprio: allow user input of per-tc max SDU net: dsa: felix: offload per-tc max SDU from tc-taprio net: enetc: cache accesses to &priv->si->hw net: enetc: offload per-tc max SDU from tc-taprio net: dsa: hellcreek: deny tc-taprio changes to per-tc max SDU net: dsa: sja1105: deny tc-taprio changes to per-tc max SDU tsnep: deny tc-taprio changes to per-tc max SDU igc: deny tc-taprio changes to per-tc max SDU net: stmmac: deny tc-taprio changes to per-tc max SDU net: am65-cpsw: deny tc-taprio changes to per-tc max SDU drivers/net/dsa/hirschmann/hellcreek.c | 5 + drivers/net/dsa/ocelot/felix_vsc9959.c | 20 +- drivers/net/dsa/sja1105/sja1105_tas.c | 6 +- drivers/net/ethernet/engleder/tsnep_tc.c | 6 +- drivers/net/ethernet/freescale/enetc/enetc.c | 28 ++- drivers/net/ethernet/freescale/enetc/enetc.h | 12 +- .../net/ethernet/freescale/enetc/enetc_pf.c | 25 ++- .../net/ethernet/freescale/enetc/enetc_qos.c | 70 +++---- drivers/net/ethernet/intel/igc/igc_main.c | 6 +- .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 6 +- drivers/net/ethernet/ti/am65-cpsw-qos.c | 6 +- include/net/pkt_sched.h | 1 + include/uapi/linux/pkt_sched.h | 11 + net/sched/sch_taprio.c | 194 +++++++++++++----- 14 files changed, 283 insertions(+), 113 deletions(-)