[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN+pFwLsSTo2DN=6A=Pxa3tjBnNcc9J7JTEKNnxk_-m4Ha9EMQ@mail.gmail.com>
Date: Fri, 19 Dec 2014 14:52:24 +0530
From: B Viswanath <marichika4@...il.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Roopa Prabhu <roopa@...ulusnetworks.com>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
John Fastabend <john.r.fastabend@...el.com>,
"Varlese, Marco" <marco.varlese@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Thomas Graf <tgraf@...g.ch>,
"sfeldma@...il.com" <sfeldma@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
On 19 December 2014 at 14:31, B Viswanath <marichika4@...il.com> wrote:
> On 19 December 2014 at 13:57, Jiri Pirko <jiri@...nulli.us> wrote:
>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichika4@...il.com wrote:
>>>On 19 December 2014 at 05:18, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>>>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
> <snipped for ease of reading>
>>>>>
>>>>>
>>>>> We also need an interface to set per-switch attributes. Can this work?
>>>>> bridge link set dev sw0 sw_attr bcast_flooding 1 master
>>>>> where sw0 is a bridge representing the hardware switch.
>>>>
>>>>
>>>> Not today. We discussed this @ LPC, and one way to do this would be to have
>>>> a device
>>>> representing the switch asic. This is in the works.
>>>
>>>
>>>Can I assume that on platforms which house more than one asic (say
>>>two 24 port asics, interconnected via a 10G link or equivalent, to get
>>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose
>>>them as a single set of ports, and not as two 'switch ports' ?
>>
>> Well that really depends on particular implementation and drivers. If you
>> have 2 pci-e devices, I think you should expose them as 2 entities. For
>> sure, you can have the driver to do the masking for you. I don't believe
>> that is correct though.
>>
>
> In a platform that houses two asic chips, IMO, the user is still
> expected to manage the router as a single entity. The configuration
> being applied on both asic devices need to be matching if not
> identical, and may not be conflicting. The FDB is to be synchronized
> so that (offloaded) switching can happen across the asics. Some of
> this stuff is asic specific anyway. Another example is that of the
> learning. The (hardware) learning can't be enabled on one asic, while
> being disabled on another one. The general use cases I have seen are
> all involving managing the 'router' as a single entity. That the
> 'router' is implemented with two asics instead of a single asic (with
> more ports) is to be treated as an implementation detail. This is the
> usual router management method that exists today.
>
> I hope I make sense.
>
> So I am trying to figure out what this single entity that will be used
> from a user perspective. It can be a bridge, but our bridges are more
> 802.1q bridges. We can use the 'self' mode, but then it means that it
> should reflect the entire port count, and not just an asic.
>
> So I was trying to deduce that in our switchdevice model, the best bet
> would be to leave the unification to the driver (i.e., to project the
> multiple physical asics as a single virtual switch device). This
> allows any 'switch' level configurations to the bridge in 'self' mode.
>
> And then we would need to consider stacking. Stacking differs from
> this multi-asic scenario since there would be multiple CPU involved.
>
> Thanks
> Vissu
>
Another example i can provide is that of mirroring. Imagine user
wanted to mirror all traffic from port 1 of asic 1 to port 2 of asic
2. This can be offloaded to hardware. However, user would be able to
enter such a command only if he/she can look at a single management
entity.
Thanks
Vissu
>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists