On Sun, Sep 1, 2019 at 4:15 PM Alexander Wetzel <alexander@xxxxxxxxxxxxxx> wrote: > > > >> Normally there are next no buffers in the tx path. When you hand over a > >> frame to the kernel it's - according what I remember when investigating > >> the issue - an atomic operation till the skb reaches mac80211 or > >> whatever other driver we use. And the few "buffers" we have are fully > >> driver controlled and we basically can just make sure those are flushed > >> when we replace the key. The only potential issue I see are traffic > >> shapers but then I think I eapol frames bypass them already. > > > the issue of race b/w set_key and send_m4 probably caused the delays in > > socket_queues/QDISC for M4, can you please elaborate on how EAPoL > > bypasses QDISC? > > I don't see PACKET_QDISC_BYPASS being set for l2_packet_send. > > I had some hope that eapol packets would have a build in fast lane but > you are right: They get added to the QDISC queue and processed like any > other packets. > > But why do we not just set PACKET_QDISC_BYPASS for eapol frames? > Just tried it and it seems to work as it should: fine. > > We could allow this setsockopt() call to fail, so all kernels < 3.14 > would continue to push the eapol packets through the QDISC. But starting > with 3.14 drivers flushing their queues prior to deleting a key can be > sure the eapol frame has been send. > > The only potential down side I can find is the - required - lack of > buffers. The driver could therefore refuse to accept the eapol packet > which should cause a disconnect instead a queued and later send eapol frame. > Using the control port for eapol would of course still better, but using > PACKET_QDISC_BYPASS when this is not working looks like a good fallback > and an improvement compared to as things are today. > I agree using that option to bypass QDISC is a definite improvment. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
