> -----Original Message----- > From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Sent: Monday, March 28, 2022 2:57 PM > To: Sriram R (QUIC) <quic_srirrama@xxxxxxxxxxx>; linux- > wireless@xxxxxxxxxxxxxxx > Cc: vkthiagu@xxxxxxxxx; Aaron Komisar <akomisar@xxxxxxxxxxxxx>; Jeff > Johnson (QUIC) <quic_jjohnson@xxxxxxxxxxx>; Jouni Malinen <j@xxxxx> > Subject: Re: [RFC] mac80211: prepare sta handling for MLO support > > WARNING: This email originated from outside of Qualcomm. Please be wary of Hi, > > > Though if we follow them through pointers, we can still allocate > > > them in the same memory chunk (just add the sizes). > > Do you mean something like, > > lsinfo = kzalloc(sizeof(*lsinfo) + sizeof(*lsta), gfp); lsta = (u8 > > *)lsinfo + sizeof(*lsinfo); > > > > This seems fine I guess and helps to do away with the second > > kzalloc(). Can we go with this? > > Need to be careful with alignment there, but otherwise yes? Sure. > > > > Not sure we need to optimise anything here though. > > > > > > Or maybe in addition or instead we should allocate an *array* of > > > links? > > > But of course only however many we actually need, regardless of > > > which ones are actually active. > > The array of link pointers are already allocated as part of struct > > ieee80211_sta and struct sta_info, right? > > Did I misunderstood? > > Correct. I meant that we should probably know how many links we need up > front, so we could allocate > > n_links * (sizeof(*lsinfo) + sizeof(*lsta)) > > kind of. > > But then again that might be more complicated? > > > We might be allocating a lot of these - so maybe it'd be worthwile to get a > kmem cache? But we can also do that later. May be I'll defer the link sta allocation changes done for reference in this RFC until we prepare a proper patch version where I could make these changes based on station_parameters being passed to add_station() op and decide how link stations will be allocated and added into the MLD STA (considering all your above inputs on optimal mem allocation for these link sta). > I'll send RFC v2 shortly with the deflink changes and spatch to update all drivers based on the new link sta struct. Thanks, Sriram.R
