From: David Lamparter <equinox@diac24.net>
To: David Miller <davem@davemloft.net>
Cc: equinox@diac24.net, netdev@vger.kernel.org, kaber@trash.net,
"Michał Mirosław" <mirqus@gmail.com>
Subject: Re: [PATCH 1/2] net: vlan: 802.1ad S-VLAN support
Date: Sat, 12 Nov 2011 15:14:29 +0100 [thread overview]
Message-ID: <20111112141429.GA41984@jupiter.n2.diac24.net> (raw)
In-Reply-To: <20111111.202235.1981500713669985784.davem@davemloft.net>
On Fri, Nov 11, 2011 at 08:22:35PM -0500, David Miller wrote:
> > @@ -87,7 +97,8 @@ struct vlan_group {
> > */
> > unsigned int nr_vlans;
> > struct hlist_node hlist; /* linked list */
> > - struct net_device **vlan_devices_arrays[VLAN_GROUP_ARRAY_SPLIT_PARTS];
> > + struct net_device **vlan_devices_arrays[VLAN_N_PROTOCOL]
> > + [VLAN_GROUP_ARRAY_SPLIT_PARTS];
> > struct rcu_head rcu;
> > };
>
> This is a terrible waste of memory. You're now using 5 times as much space,
> the vast majority of which will be entirely unused.
VLAN_GROUP_ARRAY_SPLIT_PARTS is 8; so the memory consumption of this was
previously 8 * ptr = 64 bytes and is now 5 * 8 * ptr = 320 bytes. I thought
those extra 256 bytes per VLAN-carrying master device are worth the
simplicity, especially since this saves me impacts on 802.1Q C-VLAN
lookup performance elsewhere.
The individual VLAN_GROUP_ARRAY_SPLIT_PARTS are allocated on-demand in
vlan_group_prealloc_vid (net/8021q/vlan.c). They aren't freed if they
get empty, only when all VLANs disappear; that's an issue with the
existing code that could be fixed independently.
> I don't even think it's semantically correct, all these alias QinQ protocol
> values don't provide completely new VLAN_ID name spaces at all. So this
> layout doesn't even make any sense, you're allowing for something that isn't
> even allowed.
The namespaces are separate. 802.1ad goes to quite some lengths to
replace all occurences of "VLAN ID" with "C-VLAN ID" and introduces the
separate "S-VLAN ID".
Nortel's 0x9?00 protocol values have no spec that i know of... oh, I
could save 192 bytes with an "[ ] Legacy Nortel protocol IDs" switch,
I guess.
> Rework these datastructures to eliminate the wastage please.
I could reverse the order of the id vs. protocol lookups, i.e. grab the
VLAN ID from the table as it was previously and then go hunt for the
device with the correct protocol. That'd require chain-linking or
tabling the devices and make 802.1Q normal/C-VLAN device lookups
slower, which I'd very much like to avoid.
The alternative would be a completely different structure for non-0x8100
VLANs, but that's an entirely different level of complexity there, which
I'm also trying to avoid...
Well, hmm... Suggestions?
-equi
next prev parent reply other threads:[~2011-11-12 14:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-05 16:54 [PATCH net-next 0/2] 802.1ad S-VLAN support David Lamparter
2011-11-05 16:54 ` [PATCH 1/2] net: vlan: " David Lamparter
2011-11-05 17:05 ` [PATCH iproute2] link/vlan: Add 802.1ad / QinQ support David Lamparter
2011-11-07 21:41 ` [PATCH 1/2] net: vlan: 802.1ad S-VLAN support Stephen Hemminger
2011-11-07 22:02 ` David Lamparter
2011-11-07 21:44 ` Stephen Hemminger
2011-11-07 22:18 ` David Lamparter
2011-11-12 1:22 ` David Miller
2011-11-12 9:25 ` Michał Mirosław
2011-11-12 14:14 ` David Lamparter [this message]
2011-11-12 16:06 ` Michał Mirosław
2011-11-12 22:22 ` David Miller
2011-11-05 16:54 ` [PATCH 2/2] net: vlan: remove unused struct vlan_group->hlist David Lamparter
2011-11-07 15:11 ` [PATCH net-next 0/2] 802.1ad S-VLAN support Ben Hutchings
2011-11-07 15:48 ` David Lamparter
2011-11-07 21:35 ` Ben Hutchings
2011-11-07 23:07 ` David Lamparter
2011-11-08 0:16 ` Ben Hutchings
2011-11-09 15:34 ` David Lamparter
2011-11-09 23:58 ` Ben Hutchings
2011-11-07 23:18 ` Francois Romieu
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=20111112141429.GA41984@jupiter.n2.diac24.net \
--to=equinox@diac24.net \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).