All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 7/7] mac80211: add rx decapsulation offload support
Date: Thu, 17 Dec 2020 09:08:17 +0100	[thread overview]
Message-ID: <cb011e2a7ef941ff729453087a71ab737aad98f6.camel@sipsolutions.net> (raw)
In-Reply-To: <dc5db3c0-e4bf-d8ed-3da6-5b549628a0cb@nbd.name>

On Wed, 2020-12-16 at 22:19 +0100, Felix Fietkau wrote:
> On 2020-12-16 22:03, Johannes Berg wrote:
> > On Wed, 2020-12-16 at 21:43 +0100, Felix Fietkau wrote:
> > > +	offload = assign &&
> > > +		  (sdata->vif.offload_flags & IEEE80211_OFFLOAD_DECAP_ENABLED);
> > > +
> > > +	if (offload)
> > > +		set_offload = !test_and_set_sta_flag(sta, WLAN_STA_DECAP_OFFLOAD);
> > > +	else
> > > +		set_offload = test_and_clear_sta_flag(sta, WLAN_STA_DECAP_OFFLOAD);
> > > +
> > > +	if (set_offload)
> > > +		drv_sta_set_decap_offload(local, sdata, &sta->sta, assign);
> > 
> > Some of these lines look a bit long?
> Just a tiny bit over 80 characters. Wasn't the 80 characters line limit
> removed a while back? I don't think line wrapping would make things more
> readable here.

Ok, fair point, I didn't count :-)

> > Not sure that's really the right thing to do ... we often want monitor
> > interfaces (with no flags set) for debug?
> > 
> > Or maybe we should add some tracing then (instead).
> Tracing probably makes more sense. I'm not sure pcap or radiotap can
> deal with a mix of 802.3 and 802.11 packets. Leaving offload enabled and
> silently dropping 802.3 packets seems like a bad idea to me as well.

Right. I've long felt that perhaps we should have tracing for this,
rather than relying on the extra monitor interface, but the monitor
interface is oh so convenient since you can directly use the result for
wireshark etc. :)

I guess I don't really care that much either way. Going with your
approach seems reasonable, but people will have to be aware that "just
add a monitor interface" is now going to affect things more than it used
to.

johannes


  reply	other threads:[~2020-12-17  8:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16 20:43 [PATCH 1/7] net/fq_impl: bulk-free packets from a flow on overmemory Felix Fietkau
2020-12-16 20:43 ` [PATCH 2/7] mac80211: force calculation of software hash for tx fair queueing Felix Fietkau
2020-12-17 11:54   ` Toke Høiland-Jørgensen
2020-12-17 12:20     ` Felix Fietkau
2020-12-17 13:01       ` Toke Høiland-Jørgensen
2020-12-17 15:48         ` Felix Fietkau
2020-12-17 17:26           ` Toke Høiland-Jørgensen
2020-12-17 19:07             ` Felix Fietkau
2020-12-18 12:41               ` Toke Høiland-Jørgensen
2020-12-18 13:40                 ` Felix Fietkau
2020-12-18 15:49                   ` Toke Høiland-Jørgensen
2020-12-16 20:43 ` [PATCH 3/7] net/fq_impl: drop get_default_func, move default flow to fq_tin Felix Fietkau
2020-12-17 11:55   ` Toke Høiland-Jørgensen
2020-12-16 20:43 ` [PATCH 4/7] net/fq_impl: do not maintain a backlog-sorted list of flows Felix Fietkau
2020-12-16 20:59   ` Johannes Berg
2020-12-17 12:40     ` Felix Fietkau
2020-12-16 20:43 ` [PATCH 5/7] mac80211: fix encryption key selection for 802.3 xmit Felix Fietkau
2020-12-16 20:43 ` [PATCH 6/7] mac80211: fix fast-rx encryption check Felix Fietkau
2020-12-16 20:43 ` [PATCH 7/7] mac80211: add rx decapsulation offload support Felix Fietkau
2020-12-16 21:03   ` Johannes Berg
2020-12-16 21:19     ` Felix Fietkau
2020-12-17  8:08       ` Johannes Berg [this message]
2020-12-16 21:04   ` Johannes Berg
2020-12-16 21:06     ` Felix Fietkau
2020-12-16 20:54 ` [PATCH 1/7] net/fq_impl: bulk-free packets from a flow on overmemory Johannes Berg
2020-12-16 21:28   ` Felix Fietkau
2020-12-17 12:09     ` Toke Høiland-Jørgensen
2020-12-17 11:51 ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb011e2a7ef941ff729453087a71ab737aad98f6.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.