cake does not seem to be able to access the DSCP field if not running of the inner interface

[moeller0]

Given a interface stack of:
eth2 -> eth2.7 -> pppoe-wan

cake's diffserv modes only seem to steer packets into tins other than best effort if cake is instantiated on the top most pppoe-wan. On either eth2 or eth2.7 all packets seem to end in the best effort tin.
I have not tested that yet, but this might also affect the ECN bitfield.

[tohojo]

Hmm, so looking at the kernel code, the way the pppoe code does encapsulation, it seems that we won't be able to access the inner IP header at all without doing a flow dissection to (re-)parse the headers.

And yeah, this will affect ECN marking and the TCP ACK filter as well...

[moeller0]

Can we somehow borrow the flow dissector code here, or are we better of trying to find a way to attach multiple queues to pppoe or are we simply hosed as pppoe is single threaded by itself?

[tohojo]

Can we somehow borrow the flow dissector code here, or are we better of trying to find a way to attach multiple queues to pppoe or are we simply hosed as pppoe is single threaded by itself?

We already call into the flow dissector code to do flow hashing, so should be possible to do for this as well, I guess. It'll probably have to be opt-in as that comes with quite a bit of per-packet overhead...

[moeller0]

But we run the flow dissector already, could we not just use the run we take to get the fields to calculate the flow hashes to also "liberate" ECN and DSCP information (that would at least allow sorting by DSCP, just not washing by DSCP).

[tohojo]

moeller0 ***@***.***> writes:

But we run the flow dissector already, could we not just use the run we take to get the fields to calculate the flow hashes to also "liberate" ECN and DSCP information (that would at least allow sorting by DSCP, just not washing by DSCP).

Yeah, maybe. Will have to dig a bit into the flow dissector API to figure this out...