Date: Sat, 16 Feb 2013 15:22:57 -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-Vmon%2BuSKwkEkeiUsC=Gh%2Bk=uVpZdXM5kTKtP_cmfBD0nwjg@mail.gmail.com> In-Reply-To: <CAFZ_MYLswF_3OvEg=uc5GXUAi=EipXmqj-cAWjRC9xi93V-R1Q@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Yeah - gluing TX into a single send queue is going to work, but there's definite queuing / QoS issues. You really want the management frames to be able to go out even if there's a _large_ amount of data frames going out. That's a side-issue though. I have a test patch that just wraps the output, mgmt_output and encapsulation/send routines with a TX lock. I can't wrap the whole TX path in a lock because there's some re-entrant behaviour going on (specifically net80211_start -> ampdu check -> send addba -> mgmt_output -> (re) grab TX lock). Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon%2BuSKwkEkeiUsC=Gh%2Bk=uVpZdXM5kTKtP_cmfBD0nwjg>