| Message ID | 20220914153303.1792444-11-vladimir.oltean@nxp.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Add tc-taprio support for queueMaxSDU | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| netdev/subject_prefix | success | Link |
| netdev/cover_letter | success | Series has a cover letter |
| netdev/patch_count | success | Link |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | fail | Errors and warnings before: 5 this patch: 5 |
| netdev/cc_maintainers | success | CCed 7 of 7 maintainers |
| netdev/build_clang | fail | Errors and warnings before: 5 this patch: 5 |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/check_selftest | success | No net selftest shell script |
| netdev/verify_fixes | success | No Fixes tag |
| netdev/build_allmodconfig_warn | fail | Errors and warnings before: 5 this patch: 5 |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 16 lines checked |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
> Since the driver does not act upon the max_sdu argument, deny any other > values except the default all-zeroes, which means that all traffic > classes should use the same MTU as the port itself. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > drivers/net/ethernet/engleder/tsnep_tc.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/engleder/tsnep_tc.c b/drivers/net/ethernet/engleder/tsnep_tc.c > index c4c6e1357317..82df837ffc54 100644 > --- a/drivers/net/ethernet/engleder/tsnep_tc.c > +++ b/drivers/net/ethernet/engleder/tsnep_tc.c > @@ -320,11 +320,15 @@ static int tsnep_taprio(struct tsnep_adapter *adapter, > { > struct tsnep_gcl *gcl; > struct tsnep_gcl *curr; > - int retval; > + int retval, tc; > > if (!adapter->gate_control) > return -EOPNOTSUPP; > > + for (tc = 0; tc < TC_MAX_QUEUE; tc++) > + if (qopt->max_sdu[tc]) > + return -EOPNOTSUPP; Does it make any difference if the MAC already guarantees that too long frames, which would violate the next taprio interval, will not be transmitted? MACs are able to do that, switches not. The user could be informed, that the MAC is considering the length of the frames by accepting any max_sdu value lower than the MTU of the netdev.
On Thu, Sep 15, 2022 at 09:01:19PM +0200, Gerhard Engleder wrote: > Does it make any difference if the MAC already guarantees that too > long frames, which would violate the next taprio interval, will not > be transmitted? This is not, in essence, about gate overruns, but about transmitting packets larger than X bytes for a traffic class. It also becomes about overruns and guard bands to avoid them, only in relation to certain hardware implementations. But it could also be useful for reducing latency in a given time slot with mixed traffic classes where you don't have frame preemption. > MACs are able to do that, switches not. Switches could in principle be able to do that too, but just in store and forward mode (not cut-through). > The user could be informed, that the MAC is considering the length of the > frames by accepting any max_sdu value lower than the MTU of the netdev. By accepting any max_sdu lower than the MTU of the netdev, I would expect that the observable behavior is that the netdev will not send any frame for this traffic class that is larger than max_sdu. But if you accept the config as valid and not act on it, this will not be enforced by anyone. This is because of the way in which the taprio qdisc works in full offload mode.
On 16.09.22 15:57, Vladimir Oltean wrote: > On Thu, Sep 15, 2022 at 09:01:19PM +0200, Gerhard Engleder wrote: >> Does it make any difference if the MAC already guarantees that too >> long frames, which would violate the next taprio interval, will not >> be transmitted? > > This is not, in essence, about gate overruns, but about transmitting > packets larger than X bytes for a traffic class. It also becomes about > overruns and guard bands to avoid them, only in relation to certain > hardware implementations. > > But it could also be useful for reducing latency in a given time slot > with mixed traffic classes where you don't have frame preemption. > >> MACs are able to do that, switches not. > > Switches could in principle be able to do that too, but just in store > and forward mode (not cut-through). > >> The user could be informed, that the MAC is considering the length of the >> frames by accepting any max_sdu value lower than the MTU of the netdev. > > By accepting any max_sdu lower than the MTU of the netdev, I would > expect that the observable behavior is that the netdev will not send any > frame for this traffic class that is larger than max_sdu. But if you > accept the config as valid and not act on it, this will not be enforced > by anyone. This is because of the way in which the taprio qdisc works in > full offload mode. Ok, denying max_sdu makes sense. It can be used to prevent too large frames for a traffic class by discarding them. In my opinion for MACs a software implementation would make sense even in full offload mode, because it would prevent copying frames from RAM to MAC which are discarded anyway. But that should be decided driver specific. Thanks for your explanations!
On Fri, Sep 16, 2022 at 09:53:56PM +0200, Gerhard Engleder wrote: > Ok, denying max_sdu makes sense. It can be used to prevent too large > frames for a traffic class by discarding them. > > In my opinion for MACs a software implementation would make sense even > in full offload mode, because it would prevent copying frames from RAM > to MAC which are discarded anyway. But that should be decided driver > specific. > > Thanks for your explanations! Depending on how your hardware architecture looks like, discarding the oversized frames in the driver might or might not be possible. If you have for example queues exposed to user space, you're at user space's mercy. Since for example enetc can have virtual station interfaces (essentially a set of queues with a way to reach them, by MAC address) exported using vfio-pci to a guest OS running arbitrary software, dropping them in the physical port MAC is pretty much the only way you can ensure you meet your latency target.
diff --git a/drivers/net/ethernet/engleder/tsnep_tc.c b/drivers/net/ethernet/engleder/tsnep_tc.c index c4c6e1357317..82df837ffc54 100644 --- a/drivers/net/ethernet/engleder/tsnep_tc.c +++ b/drivers/net/ethernet/engleder/tsnep_tc.c @@ -320,11 +320,15 @@ static int tsnep_taprio(struct tsnep_adapter *adapter, { struct tsnep_gcl *gcl; struct tsnep_gcl *curr; - int retval; + int retval, tc; if (!adapter->gate_control) return -EOPNOTSUPP; + for (tc = 0; tc < TC_MAX_QUEUE; tc++) + if (qopt->max_sdu[tc]) + return -EOPNOTSUPP; + if (!qopt->enable) { /* disable gate control if active */ mutex_lock(&adapter->gate_control_lock);
Since the driver does not act upon the max_sdu argument, deny any other values except the default all-zeroes, which means that all traffic classes should use the same MTU as the port itself. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> --- drivers/net/ethernet/engleder/tsnep_tc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)