All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <jiri@resnulli.us>, <sfeldma@gmail.com>, <netdev@vger.kernel.org>
Subject: Re: Question on switchdev
Date: Mon, 7 Mar 2016 18:09:42 -0500	[thread overview]
Message-ID: <56DE0A36.9090807@ti.com> (raw)
In-Reply-To: <56D8BB61.5020500@ti.com>

On 03/03/2016 05:32 PM, Murali Karicheri wrote:
> On 02/29/2016 05:29 PM, Andrew Lunn wrote:
>> On Mon, Feb 29, 2016 at 04:43:16PM -0500, Murali Karicheri wrote:
>>
>> Hi Murali
>>
>> Please can you get your email client to wrap lines at ~ 75 characters.
> Hi Andrew,
> 
> Thanks for responding. I have tried the instruction below and
> it doesn't seem to work for me. Do you know what will I have to
> set in thunderbird to do this?
> 
> http://arapulido.com/2009/12/01/enabling-line-wrapping-in-thunderbird/
> 
>>> TI Keystone netcp h/w has a switch. It has n slave ports and 1 host
>>> port. Currently the netcp driver disables the switch functionality
>>> which makes them appear as n nic ports. However we have requirement
>>> to add switch support in the driver. I have reviewed the
>>> experimental driver documentation
>>> Documentation/networking/switchdev.txt and would like to understand
>>> it better so that I can add this support to keystone netcp driver.
>>  
>>> NetCP h/w has a 1 (host port) x n (slave port) switch. It can do
>>> layer 2 forwarding between ports. In the switch mode, host driver
>>> provides the frame to the switch and switch uses the filter data
>>> base (AKA ALE table, Address Learning Engine table) to forward the
>>> packet. There is a piece of information available per frame (meta
>>> data) to decide if frame to be forwarded to a particular port or use
>>> the fdb for forward decisions.
>>
>> This makes is sound like a good fit for DSA.
>>
>> Documentation/networking/dsa/dsa.txt.
> 
> Let me check and get back to you on this and below after reading
> the above.
> 
> Murali
> 
>>
>> You probably need to implement a new tagging protocol in
>> net/dsa/tag_*.c and a driver in drivers/net/dsa/
>>
>>> 1. How does port netdev differ from regular netdev that carries data
>>>    when registering netdev? Any example you can point to?
>>
>> They don't differ at all. You consider each port of the switch to be a
>> normal Linux interface.
>>
>>> 2. I assume port netdev will appear as an interface in ifconfig -a
>>>    command and it is not assigned an IP address. Correct?
>>
>> The user can assign an address, if they want. It is a normal Linux
>> interface. They can also create a bridge, and add the interface to the
>> bridge. An advanced DSA driver will keep track of which interfaces are
>> in which bridge, and if possible, offload the bridge to the hardware.
>>
>>> 3. with 1xn switch, so we have n + 1 netdev registered with net
>>>    core? I assume, only 1 netdev is for data plane and the rest are
>>>    control plane. Is this correct?
>>
>> No. You only have netdev devices for the external ports of the
>> switch. The other port is known as the cpu port, and does not have a
>> netdev.
>>
>>> 4. We have bunch of port specific configuration that we would like
>>> to control or configure from use space using standard tools. For
>>> example, switch port state, flow control etc. Is that possible to
>>> add using this framework? ethtool update needed for this?
>>
>> The whole idea here is that the switch ports are normal Linux
>> interface. You use normal linux APIs to configure them. You probably
>> don't need to add any new features.
>>
>> One key things to get your head around. The switch is a hardware
>> accelerator for the Linux stack. You have to think how you can make
>> your switch accelerate the Linux stack. It takes people a while to get
>> this.
>>
>>       Andrew
>>
> 
> 
Andrew,

>From the high level, it looks like netcp switch meets the specifications
of a DSA hardware. Can you point me to a specific implementation that
I can use as an example to implement this for netcp?

-- 
Murali Karicheri
Linux Kernel, Keystone

  reply	other threads:[~2016-03-07 23:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 21:43 Question on switchdev Murali Karicheri
2016-02-29 22:29 ` Andrew Lunn
2016-03-03 22:32   ` Murali Karicheri
2016-03-07 23:09     ` Murali Karicheri [this message]
2016-03-09  0:39       ` Andrew Lunn
2016-03-10 15:03         ` Murali Karicheri

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=56DE0A36.9090807@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=andrew@lunn.ch \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=sfeldma@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 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.