From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     John Crispin <john@phrozen.org>
Cc:     linux-wireless@vger.kernel.org,
        Shashidhar Lakkavalli <slakkavalli@datto.com>,
        Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Subject: Re: [RFC V3 1/2] mac80211: add hw 80211 encapsulation offloading support
In-Reply-To: <46dfe65c-3bbf-7923-d358-9acec030f572@phrozen.org>
References: <20190401131416.22646-1-john@phrozen.org> <20190401131416.22646-2-john@phrozen.org> <87k1gcpwgy.fsf@toke.dk> <46dfe65c-3bbf-7923-d358-9acec030f572@phrozen.org>
Date:   Wed, 10 Apr 2019 12:16:27 +0200
Message-ID: <87ftqqw4g4.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

John Crispin <john@phrozen.org> writes:

> On 02/04/2019 11:50, Toke Høiland-Jørgensen wrote:
>> ieee80211_queue_skb() calls ieee80211_get_txq() which treats skb->data
>> like it contains an 802.11 header. That is probably not the intention
>> here, is it?
>>
>> I guess we could augment the TXQ stuctures to also handle 802.3 frames
>> (and introduce ieee80211_queue_skb_8023())? Or would it be better to
>> have a qdisc on 802.3-mode interfaces and push packets back to that? I
>> guess we'd still benefit from per-station queueing of packets even if
>> they are Ethernet frames, which would mean amending the TXQs would be
>> better?
>>
>> -Toke
>
> Hi Toke
>
> This patch guards the usage of the hdr pointer. hdr is only used for non 
> data frames which are not relevant when doing encap mode. The code will 
> then drop into the same path as for 80211 encapsulated frames. IMHO the 
> patch is correct and we do not need an additional 
> ieee80211_queue_skb_8023()  to benefit from per station TXQs. Let me 
> know if i missed something.

Ah, right, sorry, missed the change to ieee80211_get_txq() :)

-Toke