(apologies to davem for the repeat; I accidentally did a reply vs. reply-all the first time)
On Thu, Oct 5, 2017 at 1:05 PM, David Miller <da...@davemloft.net> wrote: > From: Rodney Cummings <rodney.cummi...@ni.com> > Date: Thu, 5 Oct 2017 18:41:48 +0000 > >> The IEEE Std 802.1Q specs for credit-based shaper require precise transmit >> decisions >> within a 125 microsecond window of time. >> >> Even with the Preempt RT patch or similar enhancements, that isn't very >> practical >> as software-only. I doubt that software would conform to the standard's >> requirements. >> >> This is analogous to memory, or CPU. > > I feel like this is looking for an excuse to not have to at least try to > implement > the software version of CBS. I don't understand why you attribute this to excuse-making. Is the objection due to the fact that the user interface is provided through a qdisc module? In that case, is there a better configuration interface for setting up traffic shaping registers that could be used across all the NICs that provide the capability? There are quite a number of them now, and the lack of kernel interfaces to the hardware makes coordinating the userspace effort to support the protocols far more difficult than it needs to be. As a contrasting example, look at the DCB shaping functionality, provided by the ETS shaper. It's specified in 802.1Q right next to the CBS shaper. It has no software implementation in a qdisc module as far as I can tell (although it should be less resource-intensive to implement), yet there's a whole netlink protocol for configuring it. I don't think it makes sense to tack on the dcb netlink interface to every driver that implements Qav; most don't have the DCB shapers, and the user-level control protocol for FQTSS is SRP instead of DCB's LLDP extensions, so completely different userspace tools would be required as well. I just want a simple, standard interface for configuring some fairly common and IEEE-standard hardware features related to AVB/TSN traffic shaping. Do we need our own netlink protocol for TSN configuration? It seems to be massive overkill for an interface to write a single register, but I suppose it might also be used for configuring TSN paramters in local switch devices, such as Qbv windows, which need quite a bit more information. I would be happy to do some of the work, but I'd like an idea of what kind of interface would be acceptable before writing up an RFC implementation. Levi
