On Fri, 26 Jan 2024 12:19:28 -0800, Jakub Kicinski wrote: > > > The tricky part here is that the whole devicetree bindings story for the > > > stmmac driver is filled with such configuration choices. As such, it is > > > only natural to add the property you are suggesting here. I completely > > > agree. But you can also argue that it is "wrong", because it does not > > > just describe the hardware, but also a configuration choice. > > > > Isn't this requirement of using enhanced tx desc instead of normal tx > > desc to support TBS is specific to Synopsys IP? Switching from > > normal desc to enhanced desc at the time of tc-etf qdisc offload > > cannot be done without traffic disruption, which I don't think is > > acceptable. Since this behavior is IP specific, can we consider > > this as an OS configuration choice? > > Why is traffic disruption not acceptable when TBS gets turned on? > User has to install the right qdisc to enable TBS, I presume, > installing qdiscs destroys the old ones which also leads to packet > drops. Hi Jakub, Agreed that packet loss is acceptable during qdisc install. Sorry, I'm a little out of context in the above statements. Switching between normal and enhanced desc is really not needed as enhanced desc can support transmission of packets that don't have any launch time also. So for any tbs supported queues we can enable enhanced desc for tbs during stmmac_open itself. As I mentioned in my previous reply: > > Agreed that this feature(use of enhanced desc) can be enabled from > > glue drivers. But I added this dt property, thinking this feature is > > specific and common to DWMAC core and we can enable this feature for > > stmmac platform driver without a glue driver. If this is not > > acceptable, I can think of doing this from the glue driver. Like Esben mentioned I think enabling tbs_en flag explicitly from the glue driver is the way to enable tbs support for a tx-queue right now. BR, Rohan
