[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53D92CAC.3070002@ti.com>
Date: Wed, 30 Jul 2014 23:04:36 +0530
From: Mugunthan V N <mugunthanvnm@...com>
To: John Fastabend <john.fastabend@...il.com>,
Ben Hutchings <ben@...adent.org.uk>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>,
<linux-api@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/1] ethtool: adding support for multiple slave port
configuration
On Sunday 27 July 2014 09:39 PM, John Fastabend wrote:
> On 07/26/2014 07:47 PM, Ben Hutchings wrote:
>> On Fri, 2014-07-25 at 17:58 +0530, Mugunthan V N wrote:
>>> Some Ethernet Swtich controllers like CPSW in AM335x, TI814x, DRA7x and
>>> AM43xx SoCs, Network Coprocessor in AM5K2E0x, Realtek Switch
>>> controllers
>>> etc has to capability of conneting multiple networks using L2 switching
>>> and has multiple phys. With the existing code, ethtool can communicate
>>> only to one phy.
>>>
>>> To enable user to communicate multiple phy connected to single Ethernet
>>> Switch controller, intoducing a optional new parameter in Ethtool
>>> interface
>>> to pass which slave to set/get the phy configuration.
>>
>> There was some discussion about configuration APIs for hardware/firmware
>> bridges earlier this year and I thought there was a consensus for
>> assigning a network device to each port. This would remove the need to
>> identify ports within a device. But I may have misremembered.
>>
>
> I like the approach of creating a network device for each port over
> having to use ethtool to program/discover them. I am currently looking
> at writing management applications for this and IMO it is much easier
> to discover and listen for events on network devices vs polling ethtool
> and iterating through slave indexs. Also you miss a lot of functionality
> that may be useful MTU for example that is not available configured via
> ethtool.
>
> One of the sticking points in earlier discussions was how to handle
> devices that have limited support for slave devices. When we create a
> netdev we expect the stack can bind to it and TX/RX packets which as
> I understand is not always possible? (I missed why we couldn't recv the
> packets over a switch port though with some skb->dev manipulation). In
> this case a feature flag could be used to resolve the feature
> dependencies.
>
>
John
I am also interested in participating in the above management api
development.
Regards
Mugunthan V N
--
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
Powered by blists - more mailing lists