From: Ben Hutchings <bhutchings@solarflare.com>
To: John Fastabend <john.r.fastabend@intel.com>
Cc: <roprabhu@cisco.com>, <mst@redhat.com>,
<stephen.hemminger@vyatta.com>, <davem@davemloft.net>,
<hadi@cyberus.ca>, <jeffrey.t.kirsher@intel.com>,
<netdev@vger.kernel.org>, <gregory.v.rose@intel.com>,
<krkumar2@in.ibm.com>, <sri@us.ibm.com>
Subject: Re: [net-next PATCH v1 1/7] net: add generic PF_BRIDGE:RTM_ FDB hooks
Date: Wed, 11 Apr 2012 04:23:19 +0100 [thread overview]
Message-ID: <1334114599.7150.361.camel@deadeye> (raw)
In-Reply-To: <20120409220017.3288.13746.stgit@jf-dev1-dcblab>
On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
[...]
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 1f77540..05822e5 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
[...]
> @@ -905,6 +906,19 @@ struct netdev_fcoe_hbainfo {
> * feature set might be less than what was returned by ndo_fix_features()).
> * Must return >0 or -errno if it changed dev->features itself.
> *
> + * int (*ndo_fdb_add)(struct ndmsg *ndm, struct net_device *dev,
> + * unsigned char *addr, u16 flags)
> + * Adds an FDB entry to dev for addr. The ndmsg contains flags to indicate
> + * if the dev->master FDB should be updated or the devices internal FDB.
I don't think the second sentence is helpful, as rtnl_fdb_add() will
take care of those flags.
> + * int (*ndo_fdb_del)(struct ndmsg *ndm, struct net_device *dev,
> + * unsigned char *addr)
> + * Deletes the FDB entry from dev coresponding to addr. The ndmsg
> + * contains flags to indicate if the dev->master FDB should be
> + * updated or the devices internal FDB.
Similarly here.
> + * int (*ndo_fdb_dump)(struct sk_buff *skb, struct netlink_callback *cb,
> + * struct net_device *dev, int idx)
> + * Used to add FDB entries to dump requests. Implementers should add
> + * entries to skb and update idx with the number of entries.
> */
[...
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
[...]
> +static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
[...]
> + err = -EOPNOTSUPP;
So if NTF_MASTER and NTF_SELF are both set, we can quietly fall back to
just setting one FDB? Not sure that's really desirable though
> + /* Support fdb on master device the net/bridge default case */
> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
> + struct net_device *master = dev->master;
> +
> + if (master->netdev_ops->ndo_fdb_add)
This operation is surely going to be mandatory for bridge devices, so
this check should be omitted or changed to a BUG_ON().
> + err = master->netdev_ops->ndo_fdb_add(ndm, dev, addr,
> + nlh->nlmsg_flags);
Shoudn't we return early on error?
> + }
> +
> + /* Embedded bridge, macvlan, and any other device support */
> + if ((ndm->ndm_flags & NTF_SELF) &&
> + dev->netdev_ops->ndo_fdb_add)
Error if !dev->netdev_ops->ndo_fdb_add.
> + err = dev->netdev_ops->ndo_fdb_add(ndm, dev, addr,
> + nlh->nlmsg_flags);
Wonder what we should do on error here if we've already successfully
called ndo_fdb_add on the master? Should we try to roll back the first
addition?
> + return err;
> +}
> +
> +static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
[...]
> + err = -EOPNOTSUPP;
> +
> + /* Support fdb on master device the net/bridge default case */
> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
> + struct net_device *master = dev->master;
> +
> + if (master->netdev_ops->ndo_fdb_del)
> + err = master->netdev_ops->ndo_fdb_del(ndm, dev, addr);
> + }
> +
> + /* Embedded bridge, macvlan, and any other device support */
> + if ((ndm->ndm_flags & NTF_SELF) &&
> + dev->netdev_ops->ndo_fdb_del)
> + err = dev->netdev_ops->ndo_fdb_del(ndm, dev, addr);
> + return err;
> +}
[...]
This has the same issues.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2012-04-11 3:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-09 22:00 [net-next PATCH v1 0/7] Managing the forwarding database(FDB) John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 1/7] net: add generic PF_BRIDGE:RTM_ FDB hooks John Fastabend
2012-04-11 3:23 ` Ben Hutchings [this message]
2012-04-11 14:45 ` John Fastabend
2012-04-11 16:05 ` Ben Hutchings
2012-04-11 17:22 ` John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 2/7] net: addr_list: add exclusive dev_uc_add and dev_mc_add John Fastabend
2012-04-10 8:03 ` Michael S. Tsirkin
2012-04-11 3:33 ` Ben Hutchings
2012-04-11 14:46 ` John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 3/7] net: add fdb generic dump routine John Fastabend
2012-04-11 3:45 ` Ben Hutchings
2012-04-11 14:46 ` John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 4/7] ixgbe: enable FDB netdevice ops John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 5/7] ixgbe: allow RAR table to be updated in promisc mode John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 6/7] ixgbe: UTA table incorrectly programmed John Fastabend
2012-04-09 22:00 ` [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode John Fastabend
2012-04-10 8:09 ` Michael S. Tsirkin
2012-04-10 8:14 ` Michael S. Tsirkin
2012-04-10 13:50 ` John Fastabend
2012-04-10 14:33 ` Michael S. Tsirkin
2012-04-10 15:29 ` John Fastabend
2012-04-10 15:32 ` Michael S. Tsirkin
2012-04-10 13:27 ` John Fastabend
2012-04-10 13:43 ` Michael S. Tsirkin
2012-04-10 14:25 ` John Fastabend
2012-04-10 14:35 ` Michael S. Tsirkin
2012-04-10 15:26 ` John Fastabend
2012-04-10 15:30 ` Michael S. Tsirkin
2012-04-10 15:35 ` John Fastabend
2012-04-11 0:46 ` Sridhar Samudrala
2012-04-11 1:42 ` John Fastabend
2012-04-11 8:02 ` Michael S. Tsirkin
2012-04-11 14:32 ` John Fastabend
2012-04-09 22:15 ` [net-next PATCH v1 0/7] Managing the forwarding database(FDB) Stephen Hemminger
2012-04-09 22:32 ` John Fastabend
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=1334114599.7150.361.camel@deadeye \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=gregory.v.rose@intel.com \
--cc=hadi@cyberus.ca \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.r.fastabend@intel.com \
--cc=krkumar2@in.ibm.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=roprabhu@cisco.com \
--cc=sri@us.ibm.com \
--cc=stephen.hemminger@vyatta.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.