On Thu, Sep 19, 2019 at 11:18:24AM +0300, Vladimir Oltean wrote: > On Thu, 19 Sep 2019 at 11:00, Sascha Hauer <s.ha...@pengutronix.de> wrote: > > > > Hi Vladimir, > > > > On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote: > > > Hi Sascha, > > > > > > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer <s.ha...@pengutronix.de> wrote: > > > > > > > > Hi All, > > > > > > > > We have a customer using a Marvell 88e6240 switch with Ethercat on one > > > > port and > > > > regular network traffic on another port. The customer wants to > > > > configure two things > > > > on the switch: First Ethercat traffic shall be priorized over other > > > > network traffic > > > > (effectively prioritizing traffic based on port). Second the ethernet > > > > controller > > > > in the CPU is not able to handle full bandwidth traffic, so the traffic > > > > to the CPU > > > > port shall be rate limited. > > > > > > > > > > You probably already know this, but egress shaping will not drop > > > frames, just let them accumulate in the egress queue until something > > > else happens (e.g. queue occupancy threshold triggers pause frames, or > > > tail dropping is enabled, etc). Is this what you want? > > > > If I understand correctly then the switch has multiple output queues per > > port. The Ethercat traffic will go to a higher priority queue and on > > congestion on other queues, frames designated for that queue will be > > dropped. I just talked to our customer and he verified that their > > Ethercat traffic still goes through even when the ports with the general > > traffic are jammed with packets. So yes, I think this is what I want. > > > > Yes, but I mean the egress shaper is per port, so when it goes out of > credits it goes out of credits, right? Meaning that even if EtherCAT > has higher strict priority, it will still experience latency caused by > the best-effort traffic consuming the port's global token bucket > credits. Sure, it may not be so bad as to actually cause tail drop, > but did you measure this?
I don't think this has been measured. I understand what you mean and there might be latencies introduced, but it seems the latencies are acceptable. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
