rnel.org
>> Cc: j...@resnulli.us; da...@davemloft.net; f.faine...@gmail.com;
>> ro...@cumulusnetworks.com
>> Subject: [RFC PATCH net-next 0/2] Add new switchdev device class
>>
>> From: Scott Feldman
>>
>>
>> So what next? I'd rather not build APIs around
> So with kobj, a device can have a parent. So I experimented with my
> RFC patch and changed register_switchdev to take a parent switchdev
> arg, which is NULL for leaf switchdevs:
>
> int register_switchdev(struct switchdev *sdev, const char *name,
>struct switchdev *par
.@cumulusnetworks.com
>Subject: [RFC PATCH net-next 0/2] Add new switchdev device class
>
>From: Scott Feldman
>
>
>So what next? I'd rather not build APIs around sysfs, so we need a netlink
>API
>we can build on top of this. It's not really rtnl. Maybe genl wo
From: sfel...@gmail.com
Date: Thu, 27 Aug 2015 00:16:44 -0700
> Comments?
No fundamental objections from me.
I just want to reiterate one thing I think Jiri said.
There are other kinds of devices which make up this kind of hierarchy.
I can think of two examples involving bonafide ethernet ports
On Thu, Aug 27, 2015 at 2:06 AM, Andrew Lunn wrote:
> On Thu, Aug 27, 2015 at 01:42:24AM -0700, Scott Feldman wrote:
>> On Thu, Aug 27, 2015 at 12:45 AM, Andrew Lunn wrote:
>> >> I don't know about how this overlaps with DSA platform_class. Florian?
>> >
>> > There is some overlap with DSA, but
On Thu, Aug 27, 2015 at 12:16:44AM -0700, sfel...@gmail.com wrote:
> From: Scott Feldman
>
> In the switchdev model, we use netdevs to represent switchdev ports, but we
> have no representation for the switch itself. So, introduce a new switchdev
> device class so we can define semantics and pro
On Thu, Aug 27, 2015 at 01:42:24AM -0700, Scott Feldman wrote:
> On Thu, Aug 27, 2015 at 12:45 AM, Andrew Lunn wrote:
> >> I don't know about how this overlaps with DSA platform_class. Florian?
> >
> > There is some overlap with DSA, but the current DSA model, with
> > respect to probing, is brok
On Thu, Aug 27, 2015 at 12:45 AM, Andrew Lunn wrote:
>> I don't know about how this overlaps with DSA platform_class. Florian?
>
> There is some overlap with DSA, but the current DSA model, with
> respect to probing, is broken. So this might be interesting as a way
> towards fix that.
>
> One thi
Thu, Aug 27, 2015 at 10:17:54AM CEST, sfel...@gmail.com wrote:
>On Thu, Aug 27, 2015 at 12:27 AM, Jiri Pirko wrote:
>> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
>>>From: Scott Feldman
>>>
>>>In the switchdev model, we use netdevs to represent switchdev ports, but we
>>>have n
On Thu, Aug 27, 2015 at 12:36 AM, John Fastabend
wrote:
> On 15-08-27 12:16 AM, sfel...@gmail.com wrote:
>> From: Scott Feldman
>>
>> In the switchdev model, we use netdevs to represent switchdev ports, but we
>> have no representation for the switch itself. So, introduce a new switchdev
>> devi
On Thu, Aug 27, 2015 at 12:27 AM, Jiri Pirko wrote:
> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
>>From: Scott Feldman
>>
>>In the switchdev model, we use netdevs to represent switchdev ports, but we
>>have no representation for the switch itself. So, introduce a new switchde
On 15-08-27 12:51 AM, Jiri Pirko wrote:
> Thu, Aug 27, 2015 at 09:43:54AM CEST, john.fastab...@gmail.com wrote:
>> On 15-08-27 12:27 AM, Jiri Pirko wrote:
>>> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman
In the switchdev model, we use netdevs to
[...]
>>
>> The structure I used previously which looks like your prototype I think,
>>
>> (https://github.com/jrfastab/rocker-net-next/blob/master/include/uapi/linux/if_flow.h)
>>
>> * [NFL_TABLE_IDENTIFIER_TYPE]
>> * [NFL_TABLE_IDENTIFIER]
>> * [NFL_TABLE_TABLES]
>> * [NFL_TABLE]
>> * [N
> I don't know about how this overlaps with DSA platform_class. Florian?
There is some overlap with DSA, but the current DSA model, with
respect to probing, is broken. So this might be interesting as a way
towards fix that.
One thing to keep in mind is the D in DSA. You talk about switch,
singul
Thu, Aug 27, 2015 at 09:43:54AM CEST, john.fastab...@gmail.com wrote:
>On 15-08-27 12:27 AM, Jiri Pirko wrote:
>> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
>>> From: Scott Feldman
>>>
>>> In the switchdev model, we use netdevs to represent switchdev ports, but we
>>> have no r
Thu, Aug 27, 2015 at 09:36:20AM CEST, john.fastab...@gmail.com wrote:
>On 15-08-27 12:16 AM, sfel...@gmail.com wrote:
>> From: Scott Feldman
>>
>> In the switchdev model, we use netdevs to represent switchdev ports, but we
>> have no representation for the switch itself. So, introduce a new swit
On 15-08-27 12:27 AM, Jiri Pirko wrote:
> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
>> From: Scott Feldman
>>
>> In the switchdev model, we use netdevs to represent switchdev ports, but we
>> have no representation for the switch itself. So, introduce a new switchdev
>> devic
On 15-08-27 12:16 AM, sfel...@gmail.com wrote:
> From: Scott Feldman
>
> In the switchdev model, we use netdevs to represent switchdev ports, but we
> have no representation for the switch itself. So, introduce a new switchdev
> device class so we can define semantics and programming interfaces
Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote:
>From: Scott Feldman
>
>In the switchdev model, we use netdevs to represent switchdev ports, but we
>have no representation for the switch itself. So, introduce a new switchdev
>device class so we can define semantics and programming
From: Scott Feldman
In the switchdev model, we use netdevs to represent switchdev ports, but we
have no representation for the switch itself. So, introduce a new switchdev
device class so we can define semantics and programming interfaces for the
switch itself. Switchdev device class isn't tied
20 matches
Mail list logo
