All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.r.fastabend@intel.com>
To: Ben Hutchings <bhutchings@solarflare.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 07:45:46 -0700	[thread overview]
Message-ID: <4F85991A.5030808@intel.com> (raw)
In-Reply-To: <1334114599.7150.361.camel@deadeye>

On 4/10/2012 8:23 PM, Ben Hutchings wrote:
> 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.

agreed neither seem particularly helpful I'll remove them.

> 
>> + * 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 
> 

It makes it easier to keep an embedded agent and the sw bridge in
sync if setting both flags adds the entry to both the SW bridge and
embedded bridge. But the error case gets a bit tricky as your comments
below indicate.

>> +	/* 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().

I'll just remove the check.

> 
>> +			err = master->netdev_ops->ndo_fdb_add(ndm, dev, addr,
>> +							      nlh->nlmsg_flags);
> 
> Shoudn't we return early on error?

Agreed better to return an err here.

> 
>> +	}
>> +
>> +	/* 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?
> 

The problem with rolling back is the table is likely already updated and
traffic may already be being forwarded. So I think in this case the user
will have to query the device to learn what failed. It seems like the
simplest way to handle this. I think it is unwanted to have traffic being
forwarded one way for a short period of time then rolled back.

The other idea I just had is we could clear the NTF_ bit in ndm_flags after
the successful add, del command. I believe the nlmsg gets sent back to the
user on error I would need to check on this.

>> +	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.
> 

same comment as above

> Ben.
> 

  reply	other threads:[~2012-04-11 14:45 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
2012-04-11 14:45     ` John Fastabend [this message]
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=4F85991A.5030808@intel.com \
    --to=john.r.fastabend@intel.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=gregory.v.rose@intel.com \
    --cc=hadi@cyberus.ca \
    --cc=jeffrey.t.kirsher@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.