On Sat, Jun 01, 2019 at 03:06:59PM +0300, Vladimir Oltean wrote:
> PTP frames will reconstruct the full timestamp without waiting for any
> meta (they are the meta), while other MAC-trapped frames (STP etc)
> will just carry a meaningless skb->cb when passed up the stack.
> In retrospect, it would
On Sat, Jun 01, 2019 at 01:31:34PM +0300, Vladimir Oltean wrote:
> If I dress the meta frame into a PTP frame (btw is there any
> preferable event message for this purpose?)
I would just make a L2 PTP event message from a specific source
address, just like the phyter does.
Use Ethertype ETH_P_158
On Sat, 1 Jun 2019 at 13:31, Vladimir Oltean wrote:
>
> On Sat, 1 Jun 2019 at 08:07, Richard Cochran wrote:
> >
> > On Fri, May 31, 2019 at 09:12:03PM +0300, Vladimir Oltean wrote:
> > > It won't work unless I make changes to dsa_switch_rcv.
> >
> > Or to the tagging code.
> >
> > > Right now tag
On Sat, 1 Jun 2019 at 08:07, Richard Cochran wrote:
>
> On Fri, May 31, 2019 at 09:12:03PM +0300, Vladimir Oltean wrote:
> > It won't work unless I make changes to dsa_switch_rcv.
>
> Or to the tagging code.
>
> > Right now taggers can only return a pointer to the skb, or NULL, case
> > in which D
On Fri, May 31, 2019 at 09:12:03PM +0300, Vladimir Oltean wrote:
> It won't work unless I make changes to dsa_switch_rcv.
Or to the tagging code.
> Right now taggers can only return a pointer to the skb, or NULL, case
> in which DSA will free it.
The tagger can re-write the skb. Why not reform
On Fri, May 31, 2019 at 07:16:17PM +0300, Vladimir Oltean wrote:
> But now comes the question on what to do on error cases - the meta
> frame didn't arrive. Should I just drop the skb waiting for it?
Yes, that is what other drivers do.
> Right now I "goto rcv_anyway" - which linuxptp doesn't like
On Fri, 31 May 2019 at 19:16, Vladimir Oltean wrote:
>
> On Fri, 31 May 2019 at 19:09, Richard Cochran
> wrote:
> >
> > On Fri, May 31, 2019 at 06:23:34PM +0300, Vladimir Oltean wrote:
> > > You mean to queue it and subvert DSA's own RX timestamping callback?
> >
> > No, use the callback.
> >
>
On Fri, 31 May 2019 at 19:09, Richard Cochran wrote:
>
> On Fri, May 31, 2019 at 06:23:34PM +0300, Vladimir Oltean wrote:
> > You mean to queue it and subvert DSA's own RX timestamping callback?
>
> No, use the callback.
>
> > Why would I do that? Just so as not to introduce my .can_timestamp
> >
On Fri, May 31, 2019 at 06:23:34PM +0300, Vladimir Oltean wrote:
> You mean to queue it and subvert DSA's own RX timestamping callback?
No, use the callback.
> Why would I do that? Just so as not to introduce my .can_timestamp
> callback?
Right, the .can_timestamp is unneeded, AFAICT.
> > Now
On Fri, 31 May 2019 at 18:11, Richard Cochran wrote:
>
> On Fri, May 31, 2019 at 05:27:15PM +0300, Vladimir Oltean wrote:
> > On Fri, 31 May 2019 at 17:08, Richard Cochran
> > wrote:
> > > This can be done simply using a data structure in the driver with an
> > > appropriate locking mechanism.
On Fri, May 31, 2019 at 08:11:51AM -0700, Richard Cochran wrote:
>
> 1. When the driver receives a deferred PTP frame, save it into a
>per-switch,port slot at the driver (not port) level.
>
> 2. When the driver receives a META frame, match it to the
>per-switch,port slot. If there is a P
On Fri, May 31, 2019 at 05:27:15PM +0300, Vladimir Oltean wrote:
> On Fri, 31 May 2019 at 17:08, Richard Cochran
> wrote:
> > This can be done simply using a data structure in the driver with an
> > appropriate locking mechanism. Then you don't have to worry which
> > core the driver code runs o
On Fri, 31 May 2019 at 17:08, Richard Cochran wrote:
>
> On Fri, May 31, 2019 at 04:23:24PM +0300, Vladimir Oltean wrote:
> > The switch has internal logic to not send any other frame to the CPU
> > between a link-local and a meta frame.
>
> So this is guarantied by the switch? What happens when
On Fri, May 31, 2019 at 04:23:24PM +0300, Vladimir Oltean wrote:
> The switch has internal logic to not send any other frame to the CPU
> between a link-local and a meta frame.
So this is guarantied by the switch? What happens when multiple PTP
frames arrive at the same time on different ports?
On Fri, 31 May 2019 at 07:34, Richard Cochran wrote:
>
> On Thu, May 30, 2019 at 06:23:09PM +0300, Vladimir Oltean wrote:
> > On Thu, 30 May 2019 at 18:06, Richard Cochran
> > wrote:
> > >
> > > But are the frames received in the same order? What happens your MAC
> > > drops a frame?
> > >
> >
On Thu, May 30, 2019 at 06:23:09PM +0300, Vladimir Oltean wrote:
> On Thu, 30 May 2019 at 18:06, Richard Cochran
> wrote:
> >
> > But are the frames received in the same order? What happens your MAC
> > drops a frame?
> >
>
> If it drops a normal frame, it carries on.
> If it drops a meta frame
On Thu, 30 May 2019 at 18:06, Richard Cochran wrote:
>
> On Thu, May 30, 2019 at 05:57:30PM +0300, Vladimir Oltean wrote:
> > On Thu, 30 May 2019 at 17:30, Richard Cochran
> > wrote:
> > >
> > > Not necessarily. If two frames that arrive at nearly the same time
> > > get their timestamps mixed
On Thu, May 30, 2019 at 05:57:30PM +0300, Vladimir Oltean wrote:
> On Thu, 30 May 2019 at 17:30, Richard Cochran
> wrote:
> >
> > Not necessarily. If two frames that arrive at nearly the same time
> > get their timestamps mixed up, that would be enough to break the time
> > values but without br
On Thu, 30 May 2019 at 17:30, Richard Cochran wrote:
>
> On Thu, May 30, 2019 at 12:01:23PM +0300, Vladimir Oltean wrote:
> > In fact that's why it doesn't work: because linuxptp adds ptp_dst_mac
> > (01-1B-19-00-00-00) and (01-80-C2-00-00-0E) to the MAC's multicast
> > filter, but the switch in i
On Thu, May 30, 2019 at 12:01:23PM +0300, Vladimir Oltean wrote:
> In fact that's why it doesn't work: because linuxptp adds ptp_dst_mac
> (01-1B-19-00-00-00) and (01-80-C2-00-00-0E) to the MAC's multicast
> filter, but the switch in its great wisdom mangles bytes
> 01-1B-19-xx-xx-00 of the DMAC to
On Thu, 30 May 2019 at 06:45, Richard Cochran wrote:
>
> On Wed, May 29, 2019 at 11:41:22PM +0300, Vladimir Oltean wrote:
> > I'm sorry, then what does this code from raw.c do?
>
> It is a fallback for HW that doesn't support multicast filtering.
>
> Care to look a few lines above? If you did, yo
On Wed, May 29, 2019 at 11:41:22PM +0300, Vladimir Oltean wrote:
> I'm sorry, then what does this code from raw.c do?
It is a fallback for HW that doesn't support multicast filtering.
Care to look a few lines above? If you did, you would have seen this:
memset(&mreq, 0, sizeof(mreq));
On 5/29/19 7:52 AM, Richard Cochran wrote:
On Wed, May 29, 2019 at 02:56:22AM +0300, Vladimir Oltean wrote:
Not all is rosy, though.
You can sure say that again!
PTP timestamping will only work when the ports are bridged. Otherwise,
the metadata follow-up frames holding RX timestamps won't
On Wed, May 29, 2019 at 02:56:22AM +0300, Vladimir Oltean wrote:
> Not all is rosy, though.
You can sure say that again!
> PTP timestamping will only work when the ports are bridged. Otherwise,
> the metadata follow-up frames holding RX timestamps won't be received
> because they will be blocked
This patchset adds the following:
- A timecounter/cyclecounter based PHC for the free-running
timestamping clock of this switch.
- A state machine implemented in the DSA tagger for SJA1105, which
keeps track of metadata follow-up Ethernet frames (the switch's way
of transmitting RX tim
25 matches
Mail list logo
