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;
+
 	if (!qopt->enable) {
 		/* disable gate control if active */
 		mutex_lock(&adapter->gate_control_lock);
-- 
2.34.1

> 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.