> -----Original Message----- > From: Felix Fietkau <nbd@xxxxxxxx> > Sent: Saturday, December 4, 2021 2:49 PM > To: Sriram R <srirrama@xxxxxxxxxxxxxxxx>; Sriram R (QUIC) > <quic_srirrama@xxxxxxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx > Cc: johannes@xxxxxxxxxxxxxxxx > Subject: Re: [RFC] mac80211: Mesh Fast xmit support > > WARNING: This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > On 2021-12-04 10:14, Sriram R wrote: > >> -----Original Message----- > >> From: Felix Fietkau <nbd@xxxxxxxx> > >> Sent: Saturday, December 4, 2021 1:55 PM > >> To: Sriram R (QUIC) <quic_srirrama@xxxxxxxxxxx>; linux- > >> wireless@xxxxxxxxxxxxxxx > >> Cc: johannes@xxxxxxxxxxxxxxxx > >> Subject: Re: [RFC] mac80211: Mesh Fast xmit support > >> > >> WARNING: This email originated from outside of Qualcomm. Please be > >> wary of any links or attachments, and do not enable macros. > >> > >> On 2021-12-04 03:04, Sriram R wrote: > >> > Support Fast xmit for mesh device types by caching the header > >> > corresponding to the ethernet DA and reusing the cached header > >> > (mac, mesh, llc) everytime the packet is intended for that DA. > >> > > >> > This will avoid multiple path table lookups during header > >> > generation for a mesh packet tx. > >> > > >> > Freshness of the header is verified by identifying change in mesh > >> > paths before using the header and corresponding changes to the > >> > header and cache entry is done on the fly. > >> > > >> > Mutable fields of the header such as eth SA, tid, mesh SN, PN are > >> > updated for each xmit. > >> > > >> > Each cache entry is about 100Bytes, least used/expired entries are > >> > periodically removed when cache gets almost full. > >> > Currently the size is set to 50 entries. > >> > > >> > Driver needs to advertise NL80211_EXT_FEATURE_MESH_FAST_XMIT > >> > to enable this support and setup this cache. > >> Thanks for working on this! I will likely take a closer look at it soon. > >> One quick question: does this impose any extra requirements on the > >> driver, or why does the driver need to advertise support for this? > > Hi Felix, > > > > There is no requirement from driver/hw as such and this has similar > > requirement as IEEE80211_HW_SUPPORT_FAST_XMIT being enabled from > driver. > > But I was not sure if adding ~5KB (50 entries x ~100Bytes) by default > > was acceptable for those drivers which already enabled FAST_XMIT. > > Hence added this extra control from driver to enable this feature for this > RFC. > > Kindly suggest if other alternatives could be taken up. > I think 5 KB memory use is very small compared to the memory used for > packets and other data. If this is only about memory use, it also doesn't make > much sense to me for the driver to decide if this is going to be used. > My suggestion would be to not introduce an extra capability and simply > enable it if fast-xmit is supported. Sure, Agreed > Maybe it would make sense to allow the user to configure this, because > some networks might benefit from a larger cache. Right, I'll add it in the next version. Thanks, Sriram.R > > - Felix
