Date: Sat, 16 Feb 2013 15:46:51 -0800 From: Adrian Chadd <adrian@freebsd.org> To: PseudoCylon <moonlightakkiy@yahoo.ca> Cc: freebsd-wireless@freebsd.org Subject: Re: [RFC] serialising net80211 TX Message-ID: <CAJ-VmomMnZ7EM=bgS9NpM_pYDaLQxFg5k2vd7vrdEa4oYx3XNw@mail.gmail.com> In-Reply-To: <CAJ-Vmon%2BuSKwkEkeiUsC=Gh%2Bk=uVpZdXM5kTKtP_cmfBD0nwjg@mail.gmail.com> References: <CAFZ_MYJjV=5FtEmWkO7rRBtAuvn2R0Ec=O0ojhPxBfcBuLRUJQ@mail.gmail.com> <CAJ-VmonAXBxuD51y-j5PEt4uGHO_EX15C3inj9wTmR%2BJnb21LA@mail.gmail.com> <CAFZ_MYLswF_3OvEg=uc5GXUAi=EipXmqj-cAWjRC9xi93V-R1Q@mail.gmail.com> <CAJ-Vmon%2BuSKwkEkeiUsC=Gh%2Bk=uVpZdXM5kTKtP_cmfBD0nwjg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
Hi, Here's the patch: * break out the per-packet send code into ieee80211_start_pkt() * introduce a per-vap TX lock * wrap the normal TX path ieee80211_encap(), parent->if_transmit and ic->ic_raw_xmit with the TX lock TODO: * the rest of the encap calls need to be wrapped in the TX lock - wds, superg, mesh. * the TX lock is not re-entrant but the TX path itself is (eg start -> start aggregation -> addba send -> mgmt_send -> (re) grab lock) so a bunch of this stuff needs to be rethought to be "clean" locking wise. I bet wds, superg and mesh is being called from the normal TX path and thus could be called with the TX lock already held. I should investigate this! * the TX aggregation state code should be protected by a lock - do that later? * add some lock / unlock assertion checks (eg assert the TX lock is held in ieee80211_encap()) and debug what code paths are / aren't being engaged. I'm still testing this. I've only tested it in STA mode thus far (iwn and ath.) thanks, Adrian Adrianhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomMnZ7EM=bgS9NpM_pYDaLQxFg5k2vd7vrdEa4oYx3XNw>