[PATCH 01/16] hostapd: MLO: avoid usage of mld_id as user configuration
Benjamin Berg
benjamin at sipsolutions.net
Mon Mar 18 05:25:13 PDT 2024
Hi,
On Mon, 2024-03-18 at 17:49 +0530, Aditya Kumar Singh wrote:
> On 3/18/24 16:23, Benjamin Berg wrote:
> ...
> > > diff --git a/src/ap/beacon.c b/src/ap/beacon.c
> > > index e50f0a0c976e..9c028b5b72d6 100644
> > > --- a/src/ap/beacon.c
> > > +++ b/src/ap/beacon.c
> > > @@ -960,7 +960,7 @@ static void
> > > hostapd_fill_probe_resp_ml_params(struct hostapd_data *hapd,
> > > * We want to include the AP MLD ID in the response if
> > > it
> > > was
> > > * included in the request.
> > > */
> > > - probed_mld_id = mld_id != -1 ? mld_id : hapd->conf-
> > > >mld_id;
> > > + probed_mld_id = mld_id != -1 ? mld_id :
> > > hostapd_get_mld_id(hapd);
> >
> > We are not (yet) hitting these code paths. But, I think
> > conceptually it
> > would make more sense to get the probed hapd from the MLD ID. i.e.
> > something like:
> > probed_hapd = mld_id == 0 ? hapd :
> > hostapd_get_mbssid_hapd(hapd, mld_id);
> >
>
> Yes correct. But fixes regarding MLO+MBSSID is in later part of our
> work. As you rightly said, this we are not hitting as of today. Also,
> this patch series tries to just support 1 MLD interface (as it was doing
> already before this) and at the same time just scale up certain
> structures/handling so that it can be leveraged when support for
> multiple MLD interfaces (co-hosted) is added later (this I'm working on
> right now and will probably send out series soon :)). So at that time
> this would be fixed properly.
>
> > > for_each_mld_link(link, i, j, hapd->iface->interfaces,
> > > probed_mld_id) {
> >
> > Then we need to change the iteration, but I think that makes sense
> > anyway, see below.
> >
>
> ... \
> > > @@ -794,7 +798,7 @@ int hostapd_link_remove(struct hostapd_data
> > > *hapd, u32 count);
> > > for (_link
> > > = \
> > > (_ifaces)->iface[_iface_idx]-
> > > > bss[_bss_idx]; \
> > > _link && _link->conf->mld_ap
> > > && \
> > > - _link->conf->mld_id ==
> > > _mld_id; \
> > > + hostapd_get_mld_id(_link) ==
> > > _mld_id; \
> > > _link = NULL)
> >
> > I think this part is slightly wrong, as the mld_id here would be
> > local
> > to the link, but it should to be local to the hapd from which we
> > started the iteration.
> >
> > Maybe we can update the macro and simplify it a bit at the same
> > time.
> > We always have an hapd instance anyway, so passing the interfaces
> > explicitly does not really make sense. So, we can just start with
> > an
> > hapd instance, and iterate all links (including itself). Something
> > like:
> >
> > #define for_each_mld_link(_hapd, _link, _bss_idx,
> > _iface_idx) \
> > for (_iface_idx =
> > 0; \
> > _iface_idx < (_hapd)->iface->interfaces)-
> > >count; \
> >
> > _iface_idx++) \
> > for (_bss_idx =
> > 0; \
> > _bss_idx
> > < \
> > (_ifaces)->iface[_iface_idx]-
> > >num_bss; \
> >
> > _bss_idx++) \
> > for (_link
> > = \
> > (_hapd)->iface->interfaces-
> > > \
> > iface[_iface_idx]-
> > >bss[_bss_idx]; \
> > _link
> > && \
> > hostapd_is_ml_partner(_link,
> > _hapd); \
> > _link = NULL)
> >
> > Benjamin
>
> Yeah that makes sense. Thanks for the input! But as I said above, in the
> next series, actually this logic will be replaced with another one.
> Hence did not change much here.
>
> Now (after this series) since we have all affiliated links tied up to a
> common MLD structure via a list member, there is no need of these many
> arguments for this macro. We can just use dl_list_for_each() and iterate
> over all affiliated links.
Yeah, it'll become much nicer. I had not realized you added struct
hostapd_mld when I wrote the mail.
So, with that, I am happy with it as-is :-)
Benjamin
More information about the Hostap
mailing list