Netdev List
 help / color / mirror / Atom feed
From: Alexandra Winter <wintera@linux.ibm.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: David Ahern <dsahern@gmail.com>,
	netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>,
	DENG Qingfang <dqfext@gmail.com>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	Roopa Prabhu <roopa@nvidia.com>,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH iproute2 5/6] man8/bridge.8: explain self vs master for "bridge fdb add"
Date: Mon, 15 Feb 2021 13:33:50 +0100	[thread overview]
Message-ID: <69a3c453-8cc8-08ec-0ad7-39c0452919a7@linux.ibm.com> (raw)
In-Reply-To: <20210215121342.driolhmaow7ads5g@skbuf>



On 15.02.21 13:13, Vladimir Oltean wrote:
> On Mon, Feb 15, 2021 at 11:53:42AM +0100, Alexandra Winter wrote:
>> Actually, I found your first (more verbose) proposal more helpful.
> 
> Sorry, I don't understand. Do you want me to copy the whole explanation
> from bridge fdb add to bridge link set?
> 
>>>> Maybe I misunderstand this sentence, but I can do a 'bridge fdb add' without 'self'
>>>> on the bridge device. And the address shows up under 'bridge fdb show'.
>>>> So what does mandatory mean here?
>>>
>>> It's right in the next sentence:
>>>
>>>> The flag is set by default if "master" is not specified.
>>>
>>> It's mandatory and implicit if "master" is not specified, ergo 'bridge
>>> fdb add dev br0' will work because 'master' is not specified (it is
>>> implicitly 'bridge fdb add dev br0 self'. But 'bridge fdb add dev br0
>>> master' will fail, because the 'self' flag is no longer implicit (since
>>> 'master' was specified) but mandatory and absent.
>>>
>>> I'm not sure what I can do to improve this.
>>>
>> Maybe the sentence under 'master':
>> " If the specified
>> +device is a master itself, such as a bridge, this flag is invalid."
>> is sufficient to defien this situation. And no need to explain mandatory implicit defaults
>> in the first paragraph?
> 
> I don't understand this either. Could you paste here how you think this
> paragraph should read?
> 
Sorry, I did not mean to cause confusion. Your original proposal:
 .B self
-- the address is associated with the port drivers fdb. Usually hardware
-  (default).
+- the operation is fulfilled directly by the driver for the specified network
+device. If the network device belongs to a master like a bridge, then the
+bridge is bypassed and not notified of this operation (and if the device does
+notify the bridge, it is driver-specific behavior and not mandated by this
+flag, check the driver for more details). The "bridge fdb add" command can also
+be used on the bridge device itself, and in this case, the added fdb entries
+will be locally terminated (not forwarded). In the latter case, the "self" flag
+is mandatory. The flag is set by default if "master" is not specified.
 .sp
 
 .B master
-- the address is associated with master devices fdb. Usually software.
+- if the specified network device is a port that belongs to a master device
+such as a bridge, the operation is fulfilled by the master device's driver,
+which may in turn notify the port driver too of the address. If the specified
+device is a master itself, such as a bridge, this flag is invalid.
 .sp


The above is fine with me and IMHO much better than it is today.
But if you ask me I would change it to:

 .B self
- the operation is fulfilled directly by the driver for the specified physical device. 
If the network device belongs to a master like a bridge, then the
bridge is bypassed and not notified of this operation (and if the device does
notify the bridge, it is driver-specific behavior and not mandated by this
flag, check the driver for more details). The "bridge fdb add" command can also
be used on the bridge device itself, and in this case, the added fdb entries
will be locally terminated (not forwarded). The flag is set by default if "master" 
is not specified.
 .sp
 
 .B master
- if the specified network device is a port that belongs to a master device
such as a software bridge, the operation is fulfilled by the master device's driver,
which may in turn notify the port driver too of the address. If the specified
device is a master itself, such as a bridge, this flag is invalid.
 .sp



  reply	other threads:[~2021-02-15 12:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 10:44 [PATCH iproute2 0/6] Clarifications to bridge man page Vladimir Oltean
2021-02-11 10:44 ` [PATCH iproute2 1/6] man8/bridge.8: document the "permanent" flag for "bridge fdb add" Vladimir Oltean
2021-02-11 10:44 ` [PATCH iproute2 2/6] man8/bridge.8: document that "local" is default " Vladimir Oltean
2021-02-11 10:44 ` [PATCH iproute2 3/6] man8/bridge.8: explain what a local FDB entry is Vladimir Oltean
2021-02-11 10:45 ` [PATCH iproute2 4/6] man8/bridge.8: fix which one of self/master is default for "bridge fdb" Vladimir Oltean
2021-02-11 10:45 ` [PATCH iproute2 5/6] man8/bridge.8: explain self vs master for "bridge fdb add" Vladimir Oltean
2021-02-15  8:22   ` Alexandra Winter
2021-02-15 10:32     ` Vladimir Oltean
2021-02-15 10:53       ` Alexandra Winter
2021-02-15 12:13         ` Vladimir Oltean
2021-02-15 12:33           ` Alexandra Winter [this message]
2021-02-11 10:45 ` [PATCH iproute2 6/6] man8/bridge.8: be explicit that "flood" is an egress setting Vladimir Oltean

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=69a3c453-8cc8-08ec-0ad7-39c0452919a7@linux.ibm.com \
    --to=wintera@linux.ibm.com \
    --cc=andrew@lunn.ch \
    --cc=dqfext@gmail.com \
    --cc=dsahern@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=olteanv@gmail.com \
    --cc=roopa@nvidia.com \
    --cc=stephen@networkplumber.org \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox