On Mon, 2012-03-12 at 09:48 +0100, Lennert Buytenhek wrote:
Since it can lead to problems (address database mismatches, doesn't
correctly handle STP transitions or topology changes automatically),
I think it should be avoided whenever possible. I don't see any
advantages of hardware based
On Wed, Mar 07, 2012 at 09:11:40AM -0500, Jamal Hadi Salim wrote:
Why so? (I think the switch chips should just never do learning at
all..)
I agree that learning in software gives you more flexibility;
however, I am for providing interface flexibility as well - switches
have learning
On Tue, 2012-03-06 at 15:09 +0100, Lennert Buytenhek wrote:
Why so? (I think the switch chips should just never do learning at
all..)
I agree that learning in software gives you more flexibility; however,
I am for providing interface flexibility as well - switches have
learning features. I
On Mon, 2012-03-05 at 17:53 +0100, Lennert Buytenhek wrote:
net/dsa currently configures any switch chips in the system to do
auto-learning.
So we clearly need the (user configurable) knob to turn on/off learning.
I think it should also be upto the admin to decide whether the learning
On Tue, Mar 06, 2012 at 08:42:26AM -0500, jamal wrote:
net/dsa currently configures any switch chips in the system to do
auto-learning.
So we clearly need the (user configurable) knob to turn on/off learning.
Why so? (I think the switch chips should just never do learning at
all..)
On Mon, Mar 05, 2012 at 07:45:22PM -0800, John Fastabend wrote:
Also if there are embedded switches with learning capabilities they
might want to trigger events to user space. In this case having
a protocol type makes user space a bit easier to manage. I've
added Lennert so maybe he can
On Tue, Feb 28, 2012 at 08:40:06PM -0800, John Fastabend wrote:
Also if there are embedded switches with learning capabilities they
might want to trigger events to user space. In this case having
a protocol type makes user space a bit easier to manage. I've
added Lennert so maybe he can
On Thu, Mar 01, 2012 at 08:36:20AM -0500, Jamal Hadi Salim wrote:
I want to see a unified API so that user space control applications
(RSTP, TRILL?)
can use one set of netlink calls for both software bridge and hardware
offloaded
bridges. Does this proposal meet that
On 3/5/2012 8:53 AM, Lennert Buytenhek wrote:
On Tue, Feb 28, 2012 at 08:40:06PM -0800, John Fastabend wrote:
Also if there are embedded switches with learning capabilities they
might want to trigger events to user space. In this case having
a protocol type makes user space a bit easier to
On Thu, 2012-03-01 at 14:17 -0800, John Fastabend wrote:
Hmm so I think what I'll do is this...
both: ndm_flags = 0
sw : ndm_flags = NTF_SW_FDB
hw : ndm_flags = NTF_HW_FDB
Then current tools will work with embedded bridges and software
bridges
with the interesting case being when a
On Wed, 2012-02-29 at 09:25 -0800, John Fastabend wrote:
Well I think NETLINK_ROUTE is the most correct type to use in this
case. Per netlink.h its for routing and device hooks.
#define NETLINK_ROUTE 0 /* Routing/device hook
*/
And NETLINK_ROUTE
On Wed, 2012-02-29 at 10:19 -0800, John Fastabend wrote:
I want to see a unified API so that user space control applications (RSTP,
TRILL?)
can use one set of netlink calls for both software bridge and hardware
offloaded
bridges. Does this proposal meet that requirement?
I
On Wed, Feb 29, 2012 at 09:25:56AM -0800, John Fastabend wrote:
Agreed. I think adding some ndo_ops for bridging offloads here would
work. For example the DSA infrastructure and/or macvlan devices might
need this. Along the lines of extending this RFC,
[RFC] hardware bridging support for DSA
On 3/1/2012 6:14 AM, Michael S. Tsirkin wrote:
On Wed, Feb 29, 2012 at 09:25:56AM -0800, John Fastabend wrote:
Agreed. I think adding some ndo_ops for bridging offloads here would
work. For example the DSA infrastructure and/or macvlan devices might
need this. Along the lines of extending this
On 3/1/2012 5:36 AM, Jamal Hadi Salim wrote:
On Wed, 2012-02-29 at 10:19 -0800, John Fastabend wrote:
I want to see a unified API so that user space control applications (RSTP,
TRILL?)
can use one set of netlink calls for both software bridge and hardware
offloaded
bridges. Does this
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded
switch.
PF_ROUTE:RTM_DELNEIGH -
On Tue, 2012-02-28 at 21:14 -0800, John Fastabend wrote:
Just checked looks like the DSA infrastructure has commands to enable
STP so guess it is doing learning.
IIRC, Lennert built some of this stuff tied to the kernel.
cheers,
jamal
--
To unsubscribe from this list: send the line
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded
On Wed, 29 Feb 2012 09:25:56 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
On 2/29/2012 9:52 AM, Stephen Hemminger wrote:
On Wed, 29 Feb 2012 09:25:56 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these
On 2/18/2012 4:41 AM, jamal wrote:
On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
Yes I agree that is the goal.
One last comment:
With synchronization there are other challenges when the entry in the
hardware conflicts with the entry in software when you intend the
behavior to
On 2/28/2012 8:40 PM, John Fastabend wrote:
On 2/18/2012 4:41 AM, jamal wrote:
On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
Yes I agree that is the goal.
One last comment:
With synchronization there are other challenges when the entry in the
hardware conflicts with the entry in
On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
Yes I agree that is the goal.
One last comment:
With synchronization there are other challenges when the entry in the
hardware conflicts with the entry in software when you intend the
behavior to be the same. This is not such a
On Wed, 2012-02-15 at 17:26 -0800, John Fastabend wrote:
On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
Roopa was likely on the right track here,
http://patchwork.ozlabs.org/patch/123064/
Doesnt seem related to the bridging
On Thu, 2012-02-16 at 03:58 +, Ben Hutchings wrote:
Well, in addition, there are SR-IOV network adapters that don't have any
bridge. For these, the software bridge is necessary to handle
multicast, broadcast and forwarding between local ports, not only to do
learning.
For the scenario
On 2/17/2012 6:28 AM, jamal wrote:
On Wed, 2012-02-15 at 17:26 -0800, John Fastabend wrote:
On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
Roopa was likely on the right track here,
http://patchwork.ozlabs.org/patch/123064/
Doesnt
Hello,
Please find my comments inline.
Regards,
Shradha Shah
On 02/16/2012 03:58 AM, Ben Hutchings wrote:
[I'm just catching up with this after getting my own driver changes into
shape.]
On Fri, 2012-02-10 at 10:18 -0500, jamal wrote:
Hi John,
I went backwards to summarize at the top
On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
Roopa was likely on the right track here,
http://patchwork.ozlabs.org/patch/123064/
Doesnt seem related to the bridging stuff - the modeling looks
reasonable however.
But I think the proper syntax is to use the existing
On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
Roopa was likely on the right track here,
http://patchwork.ozlabs.org/patch/123064/
Doesnt seem related to the bridging stuff - the modeling looks
reasonable however.
The operations
[I'm just catching up with this after getting my own driver changes into
shape.]
On Fri, 2012-02-10 at 10:18 -0500, jamal wrote:
Hi John,
I went backwards to summarize at the top after going through your email.
TL;DR version 0.1:
you provide a good use case where it makes sense to do
On Mon, 2012-02-13 at 07:13 -0800, John Fastabend wrote:
The use case here is multiple VFs but the same solution should work with
multiple PFs as well. FDB controls should be independent of how the ports
are exposed VFs, PFs, VMDQ/queue pairs, macvlan, etc.
Makes sense.
With events and
On 2/14/2012 5:18 AM, jamal wrote:
On Mon, 2012-02-13 at 07:13 -0800, John Fastabend wrote:
The use case here is multiple VFs but the same solution should work with
multiple PFs as well. FDB controls should be independent of how the ports
are exposed VFs, PFs, VMDQ/queue pairs, macvlan, etc.
On Tue, 14 Feb 2012 10:57:04 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/14/2012 5:18 AM, jamal wrote:
On Mon, 2012-02-13 at 07:13 -0800, John Fastabend wrote:
The use case here is multiple VFs but the same solution should work with
multiple PFs as well. FDB controls
On 2/14/2012 11:05 AM, Stephen Hemminger wrote:
On Tue, 14 Feb 2012 10:57:04 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/14/2012 5:18 AM, jamal wrote:
On Mon, 2012-02-13 at 07:13 -0800, John Fastabend wrote:
The use case here is multiple VFs but the same solution should
On Fri, 2012-02-10 at 08:39 -0800, Stephen Hemminger wrote:
Some related discussion points:
* the bridge needs to support control from both userspace (MSTP, TRILL, ...)
and kernel space (offload etc)
I think all are pretty much covered if you let some controler (I prefer
user space)
On 2/10/2012 7:18 AM, jamal wrote:
Hi John,
I went backwards to summarize at the top after going through your email.
TL;DR version 0.1:
you provide a good use case where it makes sense to do things in the
kernel. IMO, you could make the same arguement if your embedded switch
could do
On 2/9/12 9:36 AM, John Fastabend john.r.fastab...@intel.com wrote:
On 2/8/2012 8:36 PM, Stephen Hemminger wrote:
On Wed, 08 Feb 2012 19:22:06 -0800
John Fastabend john.r.fastab...@intel.com wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
Hi John,
I went backwards to summarize at the top after going through your email.
TL;DR version 0.1:
you provide a good use case where it makes sense to do things in the
kernel. IMO, you could make the same arguement if your embedded switch
could do ACLs, IPv4 forwarding etc. And the kernel
On Fri, 10 Feb 2012 10:18:31 -0500
jamal h...@cyberus.ca wrote:
Hi John,
I went backwards to summarize at the top after going through your email.
TL;DR version 0.1:
you provide a good use case where it makes sense to do things in the
kernel. IMO, you could make the same arguement if
On 2/8/2012 8:36 PM, Stephen Hemminger wrote:
On Wed, 08 Feb 2012 19:22:06 -0800
John Fastabend john.r.fastab...@intel.com wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an embedded switch is used
in
On Thu, 09 Feb 2012 09:36:47 -0800
John Fastabend john.r.fastab...@intel.com wrote:
But the device features makes it easy for user space to learn that the device
supports this sort of offload. Now if all SR-IOV devices support this then it
doesn't matter but I thought there were SR-IOV devices
On 2/9/2012 9:40 AM, Stephen Hemminger wrote:
On Thu, 09 Feb 2012 09:36:47 -0800
John Fastabend john.r.fastab...@intel.com wrote:
But the device features makes it easy for user space to learn that the device
supports this sort of offload. Now if all SR-IOV devices support this then it
On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an embedded switch is used
in hardware to do inter-VF or VF-PF switching. This patch
pushes the FDB entry
On 2/9/2012 10:14 AM, Sridhar Samudrala wrote:
On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an embedded switch is used
in hardware to do inter-VF or VF-PF
On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote:
By netlink_notifier do you mean adding a notifier_block and using
atomic_notifier_call_chain()
probably in rtnl_notify()? Then drivers could register with the notifier
chain with
atomic_notifier_chain_register() and receive the
On Thu, 2012-02-09 at 12:30 -0800, John Fastabend wrote:
On 2/9/2012 10:14 AM, Sridhar Samudrala wrote:
On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an
On 2/9/2012 4:39 PM, Sridhar Samudrala wrote:
On Thu, 2012-02-09 at 12:30 -0800, John Fastabend wrote:
On 2/9/2012 10:14 AM, Sridhar Samudrala wrote:
On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is
On 2/9/2012 1:11 PM, jamal wrote:
On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote:
By netlink_notifier do you mean adding a notifier_block and using
atomic_notifier_call_chain()
probably in rtnl_notify()? Then drivers could register with the notifier
chain with
On 2/9/2012 6:14 PM, John Fastabend wrote:
On 2/9/2012 1:11 PM, jamal wrote:
On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote:
By netlink_notifier do you mean adding a notifier_block and using
atomic_notifier_call_chain()
probably in rtnl_notify()? Then drivers could register with
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an embedded switch is used
in hardware to do inter-VF or VF-PF switching. This patch
pushes the FDB entry (specifically the MAC address) into the
embedded switch with
On Wed, 08 Feb 2012 19:22:06 -0800
John Fastabend john.r.fastab...@intel.com wrote:
Propagate software FDB table into hardware uc, mc lists when
the NETIF_F_HW_FDB is set.
This resolves the case below where an embedded switch is used
in hardware to do inter-VF or VF-PF switching. This patch
51 matches
Mail list logo
