From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Young Subject: Re: radiotap for TX Date: Thu, 21 Jun 2007 12:55:41 -0500 Message-ID: <20070621175541.GQ19613__45245.7381914884$1216696515$gmane$org@che.ojctech.com> References: <1182375853.3714.103.camel@johannes.berg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1182375853.3714.103.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org> Sender: radiotap-admin-rN9S6JXhQ+WXmMXjJBpWqg@public.gmane.org Errors-To: radiotap-admin-rN9S6JXhQ+WXmMXjJBpWqg@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Johannes Berg Cc: radiotap-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org, linux-wireless , Andy Green List-Id: radiotap@radiotap.org On Wed, Jun 20, 2007 at 11:44:13PM +0200, Johannes Berg wrote: > Hey, > > I'm currently working on using radiotap for some stuff in the Linux > wireless stack (mac80211), and ran across the case where we want > userspace to be able to send the frame to a high-priority queue. I'm > thinking this should probably be in radiotap. > > There are also other things that need to be controlled via radiotap, > here's what I can propose so far: > > * IEEE80211_RADIOTAP_SEND_AC u8 access category The MAC access parameters are an important parameter to control, but I think that if the control is self-contained, then people will use it in a predictable and consistent way. As is, you have to interpret the access category by reference to the current MAC settings for the AC (AIFS, CWmin, CWmax, et cetera), which can change. I propose that we add a field such as this, IEEE80211_RADIOTAP_TX_WMEPARAM u32 WME access parameters with three 8-bit fields for AIFS, log(CWmin), and log(CWmax), and the remaining 8 bits reserved and set to 0. This gives us the flexibility to use more MACs to the extent of their capabilities. IIRC, one Realtek MAC lets us set the access parameters packet by packet, instead of category by category or queue by queue. Some 802.11 MACs have different transmit priority queues, but the queues' access parameters are not adjustable. For those MACs, we should provide for selecting the queue by number: IEEE80211_RADIOTAP_TX_QNUM u8 queue number I think it's reasonable to say in the _TX_QNUM definition that the queue numbers do not necessarily have any relationship to queue priority level or access parameters. > * Indicates which access category to send the frame in, 0-3. > * > * IEEE80211_RADIOTAP_SEND_FLAGS u8 flags ... > IEEE80211_RADIOTAP_SEND_FLAG_SEQNR (1<<3) > /* set if the sequence number in the packet shouldn't be changed, > * if not set then the packet is sequence numbered properly */ Let's re-use and augment IEEE80211_RADIOTAP_TX_FLAGS for transmission control. For example, let the bits _F_TX_CTS/_F_TX_RTS indicate "use CTS" and "use RTS" when we transmit. But see below. Also, add _F_TX_SEQNR. > IEEE80211_RADIOTAP_SEND_FLAG_ENCRYPT (1<<0) > /* encrypt with key for the station named in addr1 or default key */ Let's re-use IEEE80211_RADIOTAP_FLAGS[IEEE80211_RADIOTAP_F_WEP] for this. > IEEE80211_RADIOTAP_SEND_FLAG_AUTO_RTSCTS (1<<1) > /* automatically decide whether rts/cts are used, if unset then > * rts/cts are used depending on IEEE80211_RADIOTAP_F_TX_{CTS,RTS} */ I believe implementors will have an easier time if you invert this: NOAUTO or (errr...) MANUAL. 16-bit fields IEEE80211_RADIOTAP_RTS_THRESHOLD and IEEE80211_RADIOTAP_CTS_THRESHOLD may be better: if absent, autoselect. If present and equal to 0, always use RTS(CTS). If present and greater than or equal to the maximum packet length, never use RTS(CTS). We can likewise control fragmentation. > IEEE80211_RADIOTAP_SEND_FLAG_RATE_CONTROL (1<<2) > /* should rate control be applied to this algorithm? if not, take > * the value of IEEE80211_RADIOTAP_RATE or lowest rate */ Control this by the presence of the _RATE parameter. If _RATE is absent, let the driver or NIC autoselect. Dave -- David Young OJC Technologies dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933 ext 24