From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81FD8C4361B for ; Thu, 17 Dec 2020 08:09:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23B2223600 for ; Thu, 17 Dec 2020 08:09:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726626AbgLQIJS (ORCPT ); Thu, 17 Dec 2020 03:09:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726416AbgLQIJS (ORCPT ); Thu, 17 Dec 2020 03:09:18 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FBD4C061794 for ; Thu, 17 Dec 2020 00:08:38 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kpoKw-00AYL0-9a; Thu, 17 Dec 2020 09:08:34 +0100 Message-ID: Subject: Re: [PATCH 7/7] mac80211: add rx decapsulation offload support From: Johannes Berg To: Felix Fietkau , linux-wireless@vger.kernel.org Date: Thu, 17 Dec 2020 09:08:17 +0100 In-Reply-To: References: <20201216204316.44498-1-nbd@nbd.name> <20201216204316.44498-7-nbd@nbd.name> <893856dcc9ff9adf65b0bcdbb6ce127d56980ee8.camel@sipsolutions.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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