Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <733b6f1a-8b07-4b23-2b10-af1ce68b6227@quicinc.com>
Date:   Wed, 3 Aug 2022 22:16:19 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [RFC 1/2] wifi: mac80211: add a new field in ieee80211_rx_status
 for link id
Content-Language: en-CA
To:     Jeff Johnson <quic_jjohnson@quicinc.com>,
        <johannes@sipsolutions.net>
CC:     <linux-wireless@vger.kernel.org>
References: <20220802065019.20791-1-quic_vthiagar@quicinc.com>
 <20220802065019.20791-2-quic_vthiagar@quicinc.com>
 <29694008-63ef-4cd3-a6c6-f82fc8377be6@quicinc.com>
From:   Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
In-Reply-To: <29694008-63ef-4cd3-a6c6-f82fc8377be6@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 8/2/2022 8:58 PM, Jeff Johnson wrote:
> On 8/1/2022 11:50 PM, Vasanthakumar Thiagarajan wrote:
>> In MLO, when the address translation from link to MLD is done
>> in fw/hw, it is necessary to be able to have some information
>> on the link on which the frame has been received. Extend the
>> rx API to include link_id in ieee80211_rx_status.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
>> ---
>>   include/net/mac80211.h | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>> index f198af600b5e..23bc34657b16 100644
>> --- a/include/net/mac80211.h
>> +++ b/include/net/mac80211.h
>> @@ -1480,6 +1480,9 @@ enum mac80211_rx_encoding {
>>    *    each A-MPDU but the same for each subframe within one A-MPDU
>>    * @ampdu_delimiter_crc: A-MPDU delimiter CRC
>>    * @zero_length_psdu_type: radiotap type of the 0-length PSDU
>> + * @link_id: id of the link used to receive the packet. Applicable 
>> only with
>> + *    MLO connection, valid link ids are in 0-14, link_id 15 means 
>> either the
>> + *    link id is not known or it is a non-MLO connection.
>>    */
>>   struct ieee80211_rx_status {
>>       u64 mactime;
>> @@ -1504,6 +1507,7 @@ struct ieee80211_rx_status {
>>       s8 chain_signal[IEEE80211_MAX_CHAINS];
>>       u8 ampdu_delimiter_crc;
>>       u8 zero_length_psdu_type;
>> +    u8 link_id;
>>   };
>>   static inline u32
> 
> in other parts of the MLO code the link_id is defined as int and a value 
> of -1 is used for a non-MLO link. but I don't know if that is currently 
> universally true.
> 
> if that is curently universally true, do we want to now have divergent 
> definitions of a link_id?

Good point, i see link_id is used both as unsigned and int based on
their usage. The reason I preferred unsigned is that we can make use of 
the remaining 4-bits for some other purpose in future, 
ieee80211_rx_status has size limitation.


Vasanth