netdev - RE: [PATCH 3/3] ocelot_ace: fix action of trap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 15 Aug 2019 12:39:52 +0000
From:   "Y.b. Lu" <yangbo.lu@....com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Richard Cochran <richardcochran@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH 3/3] ocelot_ace: fix action of trap

Hi Andrew and Allan,

I add Richard in email for help and some suggestions.
And please see my comments inline.
Thanks.

Hi Richard,

We are discussing problem of PTP message trapping to CPU on switch. Hope for your suggestions since you are the expert.
Here are the two versions patch-set.
V2: https://patchwork.ozlabs.org/project/netdev/list/?series=124713&state=*
V1: https://patchwork.ozlabs.org/project/netdev/list/?series=124563&state=*

Thanks in advance :)

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Wednesday, August 14, 2019 9:52 PM
> To: Allan W. Nielsen <allan.nielsen@...rochip.com>
> Cc: Y.b. Lu <yangbo.lu@....com>; netdev@...r.kernel.org; David S . Miller
> <davem@...emloft.net>; Alexandre Belloni <alexandre.belloni@...tlin.com>;
> Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
> Subject: Re: [PATCH 3/3] ocelot_ace: fix action of trap
> 
> On Wed, Aug 14, 2019 at 10:57:12AM +0200, Allan W. Nielsen wrote:
> > 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.
> 
> Hi Allan
> 
> The typical userspace for this is linuxptp. It implements Boundary Clock (BC),
> Ordinary Clock (OC) and Transparent Clock (TC). On switches, it works great for
> L2 PTP. But it has architectural issues for L3 PTP when used with a bridge. I've
> no idea if Richard is fixing this.

[Y.b. Lu] Right.
For the 3 scenarios Allan listed, actually I think usually the first and the second wouldn't be used if user needs 1588 synchronization.
#1 scenario, since it's PTP unaware, asymmetric delay will be introduced and it couldn't ensure sync performance.
#2 scenario, this has too much limitation. The switch hardware could only be configured as two-step end-to-end transparent clock in hardware.
For other clock types, it requires CPU handling and ptp software. In addition, ptp software takes very few resources.

So the desired scenario for 1588 synchronization should be #3 scenario.

> 
> > 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.
> 
> No, it is not. It could be the way you the implement
> ptp_clock_info.enable() does the same as what TC could do, but TC itself is not
> used, it should all be internal to the driver. And you might also want to
> consider hiding such rules from TC, otherwise the user might remove them and
> things break.

[Y.b. Lu] ptp_clock_info.enable() ?
As I understand, PTP clock driver is only for ptp clock operations, not for networking.

I would have intended to send PTP trapping rule patch for discussion after Felix driver is ready on upstream.
Let me just send TRAP option fix-up patch in next version. Will rework and send PTP trapping rule patch once Felix driver is accepted by upstream.
But I'd like to gather suggestions on that.

Thanks a lot.

> 
>      Andrew