All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Vlad Yasevich <vyasevic@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: [RFC] bridge and friends: reduce TheLinuxWay(tm)
Date: Mon, 14 Oct 2013 17:32:05 -0400	[thread overview]
Message-ID: <525C62D5.3090004@mojatatu.com> (raw)

IOW, TheCutNpasteTrain.

There's a lot of clutter on the netlink interface used
by bridge and vxlan.
1) A lot of things which are boolean on/off end up using a uchar.
Example:
IFLA_BRPORT_MODE, IFLA_BRPORT_GUARD, IFLA_BRPORT_PROTECT,
IFLA_BRPORT_LEARNING, IFLA_BRPORT_UNICAST_FLOOD, BRIDGE_VLAN_INFO_PVID,
BRIDGE_VLAN_INFO_UNTAGGED, BRIDGE_MODE_VEPA,
IFLA_VXLAN_PROXY,IFLA_VXLAN_RSC, etc

2) There's a few fields which are basically intended to project the
same message to the kernel but are redefined a few times:
Example:
BRIDGE_VLAN_INFO_MASTER vs NTF_MASTER vs BRIDGE_FLAGS_MASTER

Also i am not sure why multicast snooping needs its own subheader.

Is it too late to make changes? git logs shows some of these feature
have only been on the last 2-3 months.
One approach to resolve this is introduce a new BRIDGE_FLAGS TLV
which will work like the ifi_flags/change and put all these flags in
one spot. New iproute will use these and the old one will continue using
the old approach. It would require to EOL the old interface at some
point.

If this is agreeable and it is not on someone todo list - I will send
patches later on.

cheers,
jamal

             reply	other threads:[~2013-10-14 21:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14 21:32 Jamal Hadi Salim [this message]
2013-10-14 21:41 ` [RFC] bridge and friends: reduce TheLinuxWay(tm) Stephen Hemminger
2013-10-16 13:54   ` Jamal Hadi Salim
2013-10-16 14:05     ` Jamal Hadi Salim
2013-10-16 17:11     ` Vlad Yasevich
2013-10-16 17:49       ` Jamal Hadi Salim
2013-10-16 18:35         ` Eric Dumazet
2013-10-16 18:49           ` Stephen Hemminger
2013-10-16 18:50           ` Vlad Yasevich
2013-10-16 19:02             ` Jamal Hadi Salim
2013-10-16 20:19               ` Jamal Hadi Salim
2013-10-16 20:22                 ` Vlad Yasevich
2013-10-18 10:42                   ` Jamal Hadi Salim

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=525C62D5.3090004@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=vyasevic@redhat.com \
    /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.