Hi Y.b. and Andrew, The 08/14/2019 04:28, Y.b. Lu wrote: > > > I'd like to trap all IEEE 1588 PTP Ethernet frames to CPU through etype > > 0x88f7. > > > > Is this the correct way to handle PTP for this switch? For other switches we > > don't need such traps. The switch itself identifies PTP frames and forwards > > them to the CPU so it can process them. > > > > I'm just wondering if your general approach is wrong? > > [Y.b. Lu] PTP messages over Ethernet will use two multicast addresses. > 01-80-C2-00-00-0E for peer delay messages. Yes, and as you write, this is a BPDU which must not be forwarded (and they are not).
> 01-1B-19-00-00-00 for other messages. Yes, this is a normal L2 multicast address, which by default are broadcastet. > But only 01-80-C2-00-00-0E could be handled by hardware filter for BPDU frames > (01-80-C2-00-00-0x). For PTP messages handling, trapping them to CPU through > VCAP IS2 is the suggested way by Ocelot/Felix. As I see it there are at least 3 scenarios which needs to be considered and ideally supported: 1) Operate as a PTP-unaware switch. This means that Peer-delays messages are trapped to the CPU and not handled. End-to-End PTP sessions can still run on the network as 01-1B-19-00-00-00 frames are forwarded normally. This is what we have by default today. 2) A "passive" PTP switch (in MSCC/MCHP we call this an end-to-end transparent clock) where 01-80-C2-00-00-0E frames are still trapped to the CPU (and not handled), 01-1B-19-00-00-00 frames are forwarded, but we use the TCAM to add the residence time to the correction field in Sync and Delay request messages. This is a simple mechanism which allow end-to-end PTP sessions to synchronize their time, and compensate for the variable delay caused by the switch. Compared to implement a complete boundary clock, this is much simpler, and cause a much lower work load on the CPU (even small switches may be serving many many PTP sessions). 3) Full PTP aware switch. In this mode we need all PTP frames trapped (on the ports where PTP are running) to the CPU, and we need a PTP daemon in user-space to process them in-order for things to work. I guess this is what you are trying to achieve. Eventually, I hope we can get to a point where all (and maybe more) scenarios are supported. Lets consider them case by case: 1) This is what we have today. 2) To support this, we need a SW implementation of this, and then we can add hooks to offload this in HW. We would certainly be interested in supporting this in both SW and HW. 3) It can be done via 'tc' using the trap action, but I do not know if this is the desired way of doing it. Ocelot will be using a TCAM rule to do this, which align nicely with the 'tc' approach, but other chips may be have dedicated HW for doing this. Also, in the current implementation we will be using a rule per port, and ideally we could have done it with a single rule (this is what Y.B. prepared in this patch series). I'm very much against configuring option 3 in the driver initialization, as it will prevent us from having a conforming switch if a PTP daemon is not running in user-space, and it give us very little room for supporting other ways in the future without breaking backwards compatibility. > I have a question since you are experts. I'm not really an expert on this, but I have access to some good guidance from collages knowing PTP very well :-D > For other switches, whether they are always trapping PTP messages to CPU? Good question, I could not find anything in the SW bridge forcing option 3. My understanding is that the SW bridge is implementing option 1, but I could be wrong. > Is there any common method in linux to configure switch to select trapping or > just forwarding PTP messages? You should be able to use TC for this. But due to the port vs port-mask limitation you will need to install a rule per port. I do not know if this is what others are doing, but would like to learn about that. /Allan