Hi Jonathan,
> On Jan 7, 2018, at 01:33, Jonathan Morton <[email protected]> wrote:
>
>> On 7 Jan, 2018, at 12:46 am, Sebastian Moeller <[email protected]> wrote:
>>
>> I thibk cake should offer a mode in which it behaves as all other qdiscs
>> currently do and not do auto correction at all and a mode where it corrects
>> for the right amount, but keeping the current ake cbehavior will not help
>> anybody.... but most likely i misunderstood your proposal in that regard.
>
> Let me explain a little more clearly, using your example:
>
> Here "by default" means with no overhead keywords used at all. Currently,
> Cake does nothing with the packet lengths by default, acting as though "raw"
> was specified.
Yes, I believe we should keep a mode that does exactly that, but this
might be done with an explicit keyword IMHO. Not having that would require that
cake always does the right thing and as the history of this feature shows, this
is hard to guarantee.
>
> Instead, Cake will act as though "overhead 26" were specified on egress and
> "overhead 14" on ingress in your case.
> Unlike its current behaviour, it will recognise that it's actually getting
> raw IP packets, and won't first attempt to subtract a non-existent header
> from them. That's still different from tc-stab behaviour, but probably more
> useful.
Why behave like "overhead 26" was specified? The really desired
behaviour seems to subtract (skb->len - IP packet size) and neither the 26 nor
the 14 where actually added to skb->len. So I a still confused about what you
propose cake to report.
BTW do you see a 100% correct way to get to (skb->len - IP packet size)?
>
> Conversely, with a typical Ethernet interface, it will act as though
> "overhead 14" were specified on both egress and ingress, and will effectively
> leave the packet length alone, recognising that there is in fact an Ethernet
> frame header on the front of the packets handed in.
Ah, I begin to understand my disconnect; this is not ideal behavior as
with the overhead accounting we want to be able to "model" the bottleneck
overhead and not only the shaped interface overhead; think shaping for an IPoA
link (IP over ATM) from a non-ATM router connected via ethernet to the
ATM-modem, the 14 bytes kernel accounted overhead are neither required nor
desired, if I specify overhead 10, the kernel ideally will pass (for a full MTU
1500 packet):
1500 (MTU) + 14 (kernel added MACs/ethertype) + 10 (specified cake overhead) -
14 (remove the kernel-added MACs/ethertype)
Now, if you only talk about the case that the user did not specify an overhead
in the cake invocation, using the 1514 skb->len without further modifications,
than we violently agree. We really need this "behave like all other qdiscs"
mode so that cake can be used with "tc stab" exactly as awkward as all other
qdiscs, it would be really unfortunate if cake would require different "tc
stab" magic than say HTB+fq_codel.
>
> If you then specify "overhead 34", you'll get exactly that, relative to the
> transport-layer packet (that is, IP).
That is the best thing to do agreed, but from your description above I
am not sure about the exact conditions you propose to do that.
>
> You'll get visibility into this behaviour through the output of the current
> configuration, which will include an overhead keyword. And all this assumes
> that skb_network_offset(skb) *actually* does what I think it does.
The overhead keyword is nice in that it shows what the user requested,
but we really NEED to report also how cake interpreted that request, so we NEED
to explicitly report the auto correction value in addition to the requested
overhead (and for ease of use we maybe should also report the amount of
overhead cake added to skb->len (which equals (requested overhead - auto
correction value)))
>
> What I'm not sure about yet is whether to keep "raw"
I am not that impressed by the overloading that raw already has (ATM,
PTM, overhead...), but the functionality to not-do the auto accounting seems
required (unless we guarantee that cake always does the correct thing; and for
that we need to explicit;y report what cake "did" and what the user asked it to
do).
> and "via-ethernet" with their current meanings -
THe current via_ethernet behavior seems not requred anymore, ONCE we
unconditionally report the amount of auto corrected overhead (which could well
be 0).
> as that would probably have a (small) runtime overhead as well as requiring
> more serious thought into how to organise the configuration interface.
> Otherwise, I do intend to keep "raw" as a way to reset to the default
> configuration.
That is not what raw does ATM, for the via-ethernet mechanism raw is
not the default (how a bout a new default compound keyword?)
Best Regards
Sebastian
>
> - Jonathan Morton
>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
