All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <amwang@redhat.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Stephen Hemminger <shemminger@vyatta.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net-next v1 2/2] bridge: export multicast database via netlink
Date: Sat, 01 Dec 2012 11:56:18 +0800	[thread overview]
Message-ID: <1354334178.9680.7.camel@cr0> (raw)
In-Reply-To: <20121130152733.GH30697@casper.infradead.org>

On Fri, 2012-11-30 at 15:27 +0000, Thomas Graf wrote:
> On 11/30/12 at 11:00pm, Cong Wang wrote:
> > I don't understand this. nla_put_flag() is used to put a flag (only one
> > bit set) into a netlink message, so why should we use it to put
> > p->port_no here? And why port_no 0 matters here?
> 
> nla_put_flag() will simply add a netlink attribute with no payload,
> i.e. just the header. Assuming that port_no == 0 is invalid the
> port_no can be used as attribute id as both are 16bit integers.
> 
> It will look like this:
> 
> MDBA_ROUTERS = {
>   {
>     .nla_len = 4,
>     .nla_type = <port_no_1>,
>   },
>   {
>     .nla_len = 4,
>     .nla_type = <port_no_2>,
>   }
>   [...]
> }
> 
> If you ever need to extend this you can just add payload to the
> per port attribute and nothing will break.

Never mind, I will use port->dev->ifindex instead of port->port_no. This
will also make the user-space easier.

> 
> > So I should use net->dev_base_seq + mdb->seq ?
> 
> No you can't, mdb->seq is not stable throughout a dump. What you
> can do is save mdb->seq in cb->args[] and in case you continue
> dumping from the same mdb in the next call to your dump function
> you check if it changed and bump cb->seq if it did to trigger an
> interrupt.

Ok, will do.

Thanks!


WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <amwang@redhat.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Stephen Hemminger <shemminger@vyatta.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v1 2/2] bridge: export multicast database via netlink
Date: Sat, 01 Dec 2012 11:56:18 +0800	[thread overview]
Message-ID: <1354334178.9680.7.camel@cr0> (raw)
In-Reply-To: <20121130152733.GH30697@casper.infradead.org>

On Fri, 2012-11-30 at 15:27 +0000, Thomas Graf wrote:
> On 11/30/12 at 11:00pm, Cong Wang wrote:
> > I don't understand this. nla_put_flag() is used to put a flag (only one
> > bit set) into a netlink message, so why should we use it to put
> > p->port_no here? And why port_no 0 matters here?
> 
> nla_put_flag() will simply add a netlink attribute with no payload,
> i.e. just the header. Assuming that port_no == 0 is invalid the
> port_no can be used as attribute id as both are 16bit integers.
> 
> It will look like this:
> 
> MDBA_ROUTERS = {
>   {
>     .nla_len = 4,
>     .nla_type = <port_no_1>,
>   },
>   {
>     .nla_len = 4,
>     .nla_type = <port_no_2>,
>   }
>   [...]
> }
> 
> If you ever need to extend this you can just add payload to the
> per port attribute and nothing will break.

Never mind, I will use port->dev->ifindex instead of port->port_no. This
will also make the user-space easier.

> 
> > So I should use net->dev_base_seq + mdb->seq ?
> 
> No you can't, mdb->seq is not stable throughout a dump. What you
> can do is save mdb->seq in cb->args[] and in case you continue
> dumping from the same mdb in the next call to your dump function
> you check if it changed and bump cb->seq if it did to trigger an
> interrupt.

Ok, will do.

Thanks!

  reply	other threads:[~2012-12-01  3:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-30  9:58 [Bridge] [PATCH net-next v1 1/2] bridge: export port_no and port_id via IFA_INFO_DATA Cong Wang
2012-11-30  9:58 ` Cong Wang
2012-11-30  9:58 ` [Bridge] [PATCH net-next v1 2/2] bridge: export multicast database via netlink Cong Wang
2012-11-30  9:58   ` Cong Wang
2012-11-30 11:26   ` [Bridge] " Thomas Graf
2012-11-30 11:26     ` Thomas Graf
2012-11-30 15:00     ` [Bridge] " Cong Wang
2012-11-30 15:00       ` Cong Wang
2012-11-30 15:27       ` [Bridge] " Thomas Graf
2012-11-30 15:27         ` Thomas Graf
2012-12-01  3:56         ` Cong Wang [this message]
2012-12-01  3:56           ` Cong Wang
2012-11-30  9:58 ` [Bridge] [PATCH iproute2 v1] Add mdb command to bridge Cong Wang
2012-11-30  9:58   ` Cong Wang
2012-11-30 10:54   ` [Bridge] " Thomas Graf
2012-11-30 10:54     ` Thomas Graf
2012-11-30 14:50     ` [Bridge] " Cong Wang
2012-11-30 14:50       ` Cong Wang
2012-11-30 10:18 ` [Bridge] [PATCH net-next v1 1/2] bridge: export port_no and port_id via IFA_INFO_DATA Thomas Graf
2012-11-30 10:18   ` Thomas Graf
2012-11-30 14:51   ` [Bridge] " Cong Wang
2012-11-30 14:51     ` Cong Wang
2012-11-30 15:52 ` [Bridge] " Stephen Hemminger
2012-11-30 15:52   ` Stephen Hemminger
2012-12-01  3:53   ` [Bridge] " Cong Wang
2012-12-01  3:53     ` Cong Wang

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=1354334178.9680.7.camel@cr0 \
    --to=amwang@redhat.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.hengli.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=tgraf@suug.ch \
    /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.