Date:   Mon, 18 Mar 2019 11:03:13 +0100
From:   Stanislaw Gruszka <sgruszka@redhat.com>
To:     Felix Fietkau <nbd@nbd.name>
Cc:     linux-wireless@vger.kernel.org,
        Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Subject: Re: [PATCH 08/11] mt76x02u: implement pre TBTT work for USB
Message-ID: <20190318100313.GB3323@redhat.com>
References: <1551692896-7062-1-git-send-email-sgruszka@redhat.com>
 <1551692896-7062-9-git-send-email-sgruszka@redhat.com>
 <5844c0b8-3db9-d985-da75-a11318df37c5@nbd.name>
 <20190318095014.GA3323@redhat.com>
 <541c8464-7422-5045-217c-420ca074b36d@nbd.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <541c8464-7422-5045-217c-420ca074b36d@nbd.name>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 18, 2019 at 10:57:47AM +0100, Felix Fietkau wrote:
> On 2019-03-18 10:50, Stanislaw Gruszka wrote:
> > On Sat, Mar 16, 2019 at 08:44:21PM +0100, Felix Fietkau wrote:
> >> On 2019-03-04 10:48, Stanislaw Gruszka wrote:
> >> > Program beacons data and PS buffered frames on TBTT work for USB.
> >> > We do not have MT_TXQ_PSD queue available via USB endpoints. The way
> >> > we can send PS broadcast frames in timely manner before PS stations go
> >> > sleep again is program them in beacon data area. Hardware do not modify
> >> > those frames since TXWI is properly configured. mt76x02_mac_set_beacon()
> >> > already handle this and free no longer used frames.
> >> > 
> >> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> >> I think it's a nice idea, but there is one problem with that approach:
> >> beacon slots only have 1024 bytes for TXWI + data.
> >> I think to support this properly, you probably need to adjust beacon
> >> offsets for USB dynamically and limit the number of frames to what you
> >> can fit in SRAM.
> > That would be good since we could sent more buffered frames (ARP frames
> > are small), but for now I would prefer simpler solution to enable 
> > AP support for USB: increase slot size to 1600 and make only 5 slots
> > available.
> Then you should probably limit the number of AP interfaces for USB as
> well. Otherwise, people are going to do crazy things like bring up 4
> virtual AP interfaces and expect multicast to work :)
Yes, sure, for now only one is allowed. Multi vifs for USB is on my
TODO list.

Stanislaw