Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1572957714-16085-1-git-send-email-tamizhr@codeaurora.org>
 <20191108093207.uv4j44xpm2qvtsv5@bars> <84ca3a8b61757360ab9898afcdd3f2f63c770f86.camel@sipsolutions.net>
 <20191108120504.ptl25hacxcftb7tw@bars> <1c553c457024b295c7d0a6b118c3848eec28bcbd.camel@sipsolutions.net>
 <20191108160121.tbatmqwx64aoqqai@bars> <c95e9e9f5539150459f97f811b784a6e9af163cf.camel@sipsolutions.net>
In-Reply-To: <c95e9e9f5539150459f97f811b784a6e9af163cf.camel@sipsolutions.net>
From:   Sergey Matyukevich <geomatsi@gmail.com>
Date:   Fri, 8 Nov 2019 23:39:50 +0300
Message-ID: <CAFGfvX444gsRvbtTecJyQgYHRF3ATajUA21NkVah8AV-WxkoWg@mail.gmail.com>
Subject: Re: [PATCHv8 0/6] cfg80211/mac80211: Add support for TID specific configuration
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>,
        Tamizh chelvam <tamizhr@codeaurora.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

> > > I think we still need NL80211_TID_CONFIG_ATTR_OVERRIDE in some way
> > > (maybe only as a flag attribute), since you could have
> > >
> > >  * change all stations (some subset of TIDs) *including* already
> > >    configured stations
> > >  * or *excluding* already configured stations
> >
> > Hmmm... Logic is straightforwad without this flag:
> > - settings are applied to bitmasked TIDs of a single peer if address is specifed
> > - settings are applied to bitmasked TIDs of all the peers if no address is specified
>
> Sure, this is obvious, but what exactly does "all the peers" mean?
>
> Say I do
>
> set_tid_config(tids=0x1, peer=02:11:22:33:44:55, noack=yes)
> set_tid_config(tids=0x1, peer=NULL, noack=no)
>
> Does that reset peer 02:11:22:33:44:55, or not? This is not documented
> right now, and one could argue both ways - the override for that
> particular peer should stick, or should be removed. Which one is it?

Ok, I got the point. My understanding was that any further command would rewrite
the previous settings. But now I agree that this is not obvious and should be
explicitly documented.

Sergey