Hi Po,
> > >
> > > [Po] Ya, there are operations of switchdev. You may think that to add the
> > > TSN
> > configurations ops into switchdev operations. But we need to consider the
> > end-
> > station devices and switch all in the devices or in the TSN domain. The TSN
> > domain is the devices include TSN capabilities ports, for up layer, we need
> > to
> > provide a formal interface. So tsn configure can be standalone.
> > > In this patch, we treat two kinds of ports when registering the ports,
> > > end-
> > station or switch. This may treat them in some minor differences in TSN spec
> > and drivers.
> > >
> >
> > Why are switches different than end-stations configuration wise?
>
> Minor differences but still have mentioned in spec.
>
> > I understand that you may need to support different TSN IEEE standards per
> > device, but adding support for different capabilities shouldn't affect a
> > 'common'
> > configuration path.
> > That's the actual advantage of switchdev based drivers. switches and end
> > stations will have a very similar way of confiration via iproute2/bridge/tc
> > utils.
> > Am i missing something?
> >
> I guess I start to getting your advise. Do you mean to add operations in
> struct switchdev_ops ? Is it proper include end station? I used to add
> structure tsn_ops in net_device. But I think there are some information and
> status of devices maintain in the kernel from drivers. So I create structure
> tsn_port standalone.
> Yes, iproute2/bridge/tc is one choice for user space. I would think of the
> possible. But the too many parameters are still the problem. For example to
> create Qbv gate list.
Well iproute2 is already used to configure an 802.1Qbv software scheduler which
is already merged into net-next [1].
The netdevice operations already have a callback to configure hardware
schedulers used for CBS currently [2]. We should be able to configure the
hardware (at least the basics) for 802.1Qbv, using those callbacks.
Try to include switchdev maintainers in the next RFC and have a discussion on
what's the best approach to move forward on that and how to add missing
features.
I am not really sure i have all the bits and pieces correctly, but i did make a
presentation a few months ago on this [3].
Since switchdev is creating 1 ethernet interface per switch port and provides
you with a way of configuring the switch 'cpu' port individually we should be
able to fit everything in there by extending the current API's (but i might be
missing something).
[1] Look into net/sched/sch_taprio.c for the software scheduler.
[2] .ndo_setup_tc() is the ndo callback. Look for TC_SETUP_QDISC_CBS and you'll
get the idea. I know intel i210 and TI's cpsw driver are using it.
[3] https://connect.linaro.org/resources/yvr18/sessions/yvr18-212/
/Ilias
