linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: B Viswanath <marichika4@gmail.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	John Fastabend <john.r.fastabend@intel.com>,
	"Varlese, Marco" <marco.varlese@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Thomas Graf <tgraf@suug.ch>,
	"sfeldma@gmail.com" <sfeldma@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
Date: Fri, 19 Dec 2014 15:05:27 +0530	[thread overview]
Message-ID: <CAN+pFwJr7TvJEW4x_HYPgTEvYGfi+YHgp=5vek2YiU1GLiH6_g@mail.gmail.com> (raw)
In-Reply-To: <20141219092308.GF1848@nanopsycho.orion>

On 19 December 2014 at 14:53, Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Dec 19, 2014 at 10:01:46AM CET, marichika4@gmail.com wrote:
>>On 19 December 2014 at 13:57, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Fri, Dec 19, 2014 at 06:14:57AM CET, marichika4@gmail.com wrote:
>>>>On 19 December 2014 at 05:18, Roopa Prabhu <roopa@cumulusnetworks.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). Thist
>
> Is it possible to have the asic as just single one? Or is it possible to
> connect asics being multiple chips maybe from multiple vendors together?

I didn't understand the first question. Some times, it is possible to
have a single asic replace two, but its a cost factor, and others that
are involved.

AFAIK, the answer to the second question is a No. Two asics from
different vendors may not be connected together. The interconnect
tends to be proprietary.

> I believe that answer is "yes" in both cases. Making two separate asics
> to appear as one for user is not correct in my opinion. Driver should
> not do such masking. It is unclean, unextendable.
>

I am only looking for a single management entity. I am not thinking it
needs to be at driver level. I am not sure of  any other option apart
from creating a 'switchdev' that Roopa was mentioning.

>
>>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
>>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-12-19  9:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 11:29 [RFC PATCH net-next v2 1/1] net: Support for switch port configuration Varlese, Marco
2014-12-18 11:41 ` Thomas Graf
2014-12-18 15:20   ` Varlese, Marco
2014-12-18 14:44 ` Roopa Prabhu
2014-12-18 14:55   ` Varlese, Marco
2014-12-18 15:16     ` Roopa Prabhu
2014-12-18 17:25       ` Varlese, Marco
2014-12-18 17:49         ` Roopa Prabhu
2014-12-18 18:02           ` Varlese, Marco
2014-12-18 18:14             ` Roopa Prabhu
2014-12-18 19:21               ` John Fastabend
2014-12-18 22:43                 ` Arad, Ronen
2014-12-19  8:14                   ` Jiri Pirko
2014-12-18 23:07                 ` Roopa Prabhu
2014-12-18 23:26                   ` Samudrala, Sridhar
2014-12-18 23:48                     ` Roopa Prabhu
2014-12-19  5:14                       ` B Viswanath
2014-12-19  8:27                         ` Jiri Pirko
2014-12-19  9:01                           ` B Viswanath
2014-12-19  9:22                             ` B Viswanath
2014-12-19  9:35                               ` Jiri Pirko
2014-12-19  9:23                             ` Jiri Pirko
2014-12-19  9:35                               ` B Viswanath [this message]
2014-12-19  9:55                                 ` Jiri Pirko
2014-12-19 10:53                                   ` B Viswanath
2014-12-19 16:22                                   ` Roopa Prabhu
2014-12-20  0:57                                     ` Williams, Kenneth
2014-12-19 14:50                                 ` Andy Gospodarek
2014-12-19  8:25                       ` Jiri Pirko
2014-12-19  0:45             ` Thomas Graf
2014-12-18 15:47     ` Arad, Ronen
2014-12-18 16:14       ` John Fastabend
2014-12-18 17:17         ` Arad, Ronen

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='CAN+pFwJr7TvJEW4x_HYPgTEvYGfi+YHgp=5vek2YiU1GLiH6_g@mail.gmail.com' \
    --to=marichika4@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=john.r.fastabend@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.varlese@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    --cc=sfeldma@gmail.com \
    --cc=sridhar.samudrala@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).