Am 13.09.19 um 16:33 schrieb Denis Kenzior:
Hi Arend, Alexander,
Basically, we now have two bypass methods dealing with the
same/similar issue:
1) bypass the QDISC.
2) bypass network stack entirely with CONTROL_PORT.
It also raises the question in my mind as to why we have two ways of
doing the same thing? From the discussion so far it also sounds like
each requires somewhat different / special handling in the driver.
Wouldn't it make sense to deprecate one and encourage drivers to
implement the other?
My understanding is, that any control port frame must bypass any queues
and just send out the frame directly, correct? Any packets send via it
is directly jumping to the very front and is immediately send out.
And that the intend of it is to replace the "old" path.
So the best way forward here would be to
1) implement the patch here to work around the problem without
control_port or the theoretical QDISC bypass
2) start implementing control port for the future.
correct?
CONTROL_PORT was added specifically to take care of the re-keying races
and can be extended with additional attributes over time, as needed
(perhaps for extended key id, etc). Also note that in our testing
CONTROL_PORT is _way_ faster than PAE socket...
Extended Key ID is pretty robust when rekeying and the driver/card only
has to take care to not mix KeyIDs within one A-MPDU. It's no problem
encrypting eapol#4 with the new key. You can even encrypt it at the
initial connect and it will work. Basically all races the "classical"
rekey has to work around go away.
For "normal" rekeys it's working pretty well with ath9k and iwlwifi even
without control_port and just learned some weeks ago that QDISC could
still cause issues...
Alexander
