From: Johannes Berg <johannes@sipsolutions.net>
To: Michael Braun <michael-dev@fami-braun.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/3] mac80211: filter multicast data packets on AP / AP_VLAN
Date: Fri, 30 Sep 2016 09:20:37 +0200 [thread overview]
Message-ID: <1475220037.17481.3.camel@sipsolutions.net> (raw)
In-Reply-To: <1474821596-12155-2-git-send-email-michael-dev@fami-braun.de> (sfid-20160925_184004_593715_152E8F66)
[snip]
I think this makes sense, but it's not clear to me why you add two
counters and keep the old one? It seems to me that it would be
sufficient to have a single counter per AP/VLAN interface?
The usage in __ieee80211_request_smps_ap() can just be removed since it
goes to iterate the stations next. That should be a separate, first,
patch in the series, but after that I don't see a need to keep
num_mcast_sta, or rather, I see no reason not to remove the VLAN
stations from the AP's num_mcast_sta, and add a new per-VLAN
num_mcast_sta.
> +/**
> + * @returns number of multicast stations connected
> + * -1 if unsupported (no-AP, 4addr mode)
> + */
> +static inline int
> +ieee80211_vif_get_num_mcast_if(struct ieee80211_sub_if_data *sdata)
That's not a valid kernel-doc comment, but you've tagged it as one with
the /** - please fix by removing the /** and the @, and writing a real
sentence out of that, or by making it a real kernel-doc comment.
johannes
next prev parent reply other threads:[~2016-09-30 7:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-25 16:39 [PATCH 0/3] mac80211: multicast with AP_VLAN optimizations Michael Braun
2016-09-25 16:39 ` [PATCH 1/3] mac80211: filter multicast data packets on AP / AP_VLAN Michael Braun
2016-09-30 7:20 ` Johannes Berg [this message]
2016-09-25 16:39 ` [PATCH 2/3] mac80211: multicast to unicast conversion Michael Braun
2016-09-30 7:29 ` Johannes Berg
2016-10-04 4:36 ` M. Braun
2016-10-04 6:56 ` Johannes Berg
2016-09-25 16:39 ` [PATCH 3/3] mac80211: cache the only AP_VLAN station Michael Braun
2016-09-30 9:47 ` Johannes Berg
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=1475220037.17481.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michael-dev@fami-braun.de \
/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.