On 9/18/19 8:03 AM, Dave Taht wrote: > On Wed, Sep 18, 2019 at 7:37 AM Vladimir Oltean <olte...@gmail.com> 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? It sounds a bit > > Dropping in general is a basic attribute of the fq_codel algorithm which is > enabled by default on many boxes. It's latency sensitive, so it responds well > to pause frame (over) use. > > Usually the cpu to switch port is exposed via vlan (e.g eth0:2), and > while you can inbound and > outbound shape on that - using htb/hfsc + fq_codel, or cake
That may be true with swconfig in OpenWrt, but this is not true with DSA unless DSA_TAG_PROTO_8021Q is used which happens to be on just one driver at the moment. With other switches that support a proprietary switch tag format, there is not a particular VLAN or even a network interface that describes the CPU port, other than the DSA master network device which is the side facing the host system (not the switch itself). > > But, also, most usually what happens when the cpu cannot keep up with > the switch is we drop packets on the rx ring for receive, and in > fq-codel on send. Dave, you seem to have a tendency to just pattern match on specific QoS- related topics appearing on netdev and throwing the wonderful tool that fq_codel without necessarily considering whether this is applicable or not to the people raising the questions. Since we are talking about hardware switches here and not simply stations on a network (although the Ethernet MAC behind the CPU port ends up being one), there is the possibility of using the HW to do ingress and/or egress policing. The question raised by Sascha is how to avoid statically configuring and instead using possibly existing tools to achieve the same configuration, from user-space, that is, not encode policy in the driver, but just the mechanism. -- Florian
