On Mon, Dec 07, 2020 at 12:42:33PM -0800, Jakub Kicinski wrote:
> The behavior is not entirely dissimilar to the time stamps on
> multi-layered devices (e.g. DSA switches). The time stamp can either
> be generated when the packet enters the device (current mlx5 behavior)
> or when it actually egr
On Mon, 2020-12-07 at 12:42 -0800, Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 07:19:06 -0800 Richard Cochran wrote:
> > On Mon, Dec 07, 2020 at 12:37:45AM -0800, Saeed Mahameed wrote:
> > > we are not adding any new mechanism.
> >
> > Sorry, I didn't catch the beginning of this thread. Are you
On Mon, 7 Dec 2020 07:19:06 -0800 Richard Cochran wrote:
> On Mon, Dec 07, 2020 at 12:37:45AM -0800, Saeed Mahameed wrote:
> > we are not adding any new mechanism.
>
> Sorry, I didn't catch the beginning of this thread. Are you proposing
> adding HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY to net_tstamp.
On Sun, 6 Dec 2020 15:36:38 +0200 Eran Ben Elisha wrote:
> On 12/5/2020 1:17 AM, Jakub Kicinski wrote:
> >> We only forward ptp traffic to the new special queue but we create more
> >> than one to avoid internal locking as we will utilize the tx softirq
> >> percpu.
> > In other words to make the
On Mon, Dec 07, 2020 at 12:37:45AM -0800, Saeed Mahameed wrote:
> we are not adding any new mechanism.
Sorry, I didn't catch the beginning of this thread. Are you proposing
adding HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY to net_tstamp.h ?
If so, then ...
> Our driver feature is and internal enhanceme
On 12/7/2020 10:37 AM, Saeed Mahameed wrote:
On Sun, 2020-12-06 at 09:08 -0800, Richard Cochran wrote:
On Sun, Dec 06, 2020 at 03:37:47PM +0200, Eran Ben Elisha wrote:
Adding new enum to the ioctl means we have add
(HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY for example) all the way -
drivers,
kernel
On Sun, 2020-12-06 at 09:08 -0800, Richard Cochran wrote:
> On Sun, Dec 06, 2020 at 03:37:47PM +0200, Eran Ben Elisha wrote:
> > Adding new enum to the ioctl means we have add
> > (HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY for example) all the way -
> > drivers,
> > kernel ptp, user space ptp, ethtool.
> >
On Sat, 2020-12-05 at 00:55 +, Vladimir Oltean wrote:
> Hi Jakub,
>
> On Fri, Dec 04, 2020 at 02:52:40PM -0800, Jakub Kicinski wrote:
> > On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > > Why not use the PTP classification helpers we already have?
> > >
> > > do you mean ptp_pa
On Sat, 2020-12-05 at 03:49 +0200, Vladimir Oltean wrote:
> On Fri, Dec 04, 2020 at 12:26:13PM -0800, Jakub Kicinski wrote:
> > On Fri, 04 Dec 2020 11:33:26 -0800 Saeed Mahameed wrote:
> > > On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> > > > On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mah
On Sun, Dec 06, 2020 at 03:37:47PM +0200, Eran Ben Elisha wrote:
> Adding new enum to the ioctl means we have add
> (HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY for example) all the way - drivers,
> kernel ptp, user space ptp, ethtool.
>
> My concerns are:
> 1. Timestamp applications (like ptp4l or similar)
On 12/5/2020 2:24 AM, Jakub Kicinski wrote:
On Fri, 04 Dec 2020 15:57:36 -0800 Saeed Mahameed wrote:
On Fri, 2020-12-04 at 15:17 -0800, Jakub Kicinski wrote:
On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
option 2) route PTP traffic to a special SQs per ring, this SQ
will
be
PTP p
On 12/5/2020 1:17 AM, Jakub Kicinski wrote:
We only forward ptp traffic to the new special queue but we create more
than one to avoid internal locking as we will utilize the tx softirq
percpu.
In other words to make the driver implementation simpler we'll have
a pretty basic feature hidden be
On 12/4/2020 11:57 PM, Saeed Mahameed wrote:
We only forward ptp traffic to the new special queue but we create more
than one to avoid internal locking as we will utilize the tx softirq
percpu.
After double checking the code it seems Eran and Tariq have decided to
forward all UDP traffic, let
On Sat, Dec 05, 2020 at 03:49:27AM +0200, Vladimir Oltean wrote:
> So there you go, it just says "the reference plane marking the boundary
> between the PTP node and the network". So it depends on how you draw the
> borders.
It depends on the physical link technology. You can't just "draw the
bor
On Sat, 5 Dec 2020 03:49:27 +0200 Vladimir Oltean wrote:
> So there you go, it just says "the reference plane marking the boundary
> between the PTP node and the network". So it depends on how you draw the
> borders. I cannot seem to find any more precise definition.
Ah, you made me go search :)
On Fri, Dec 04, 2020 at 12:26:13PM -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 11:33:26 -0800 Saeed Mahameed wrote:
> > On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> > > On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> > > > Add TX PTP port object support for better TX
Hi Jakub,
On Fri, Dec 04, 2020 at 02:52:40PM -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > Why not use the PTP classification helpers we already have?
> >
> > do you mean ptp_parse_header() or the ebpf prog ?
> > We use skb_flow_dissect() which shoul
On Fri, 04 Dec 2020 15:57:36 -0800 Saeed Mahameed wrote:
> On Fri, 2020-12-04 at 15:17 -0800, Jakub Kicinski wrote:
> > On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > > > option 2) route PTP traffic to a special SQs per ring, this SQ
> > > > > will
> > > > > be
> > > > > PTP port
On Fri, 2020-12-04 at 15:17 -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > > option 2) route PTP traffic to a special SQs per ring, this SQ
> > > > will
> > > > be
> > > > PTP port accurate, Normal traffic will continue through regular
> > > > SQs
> >
On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > option 2) route PTP traffic to a special SQs per ring, this SQ will
> > > be
> > > PTP port accurate, Normal traffic will continue through regular SQs
> > >
> > > Pros: Regular non PTP traffic not affected.
> > > Cons: High memory foot
On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > Why not use the PTP classification helpers we already have?
>
> do you mean ptp_parse_header() or the ebpf prog ?
> We use skb_flow_dissect() which should be simple enough.
Not sure which exact one TBH, I just know we have helpers for
On Fri, 2020-12-04 at 12:26 -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 11:33:26 -0800 Saeed Mahameed wrote:
> > On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> > > On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> > > > Add TX PTP port object support for better TX times
On Fri, 04 Dec 2020 11:33:26 -0800 Saeed Mahameed wrote:
> On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> > On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> > > Add TX PTP port object support for better TX timestamping accuracy.
> > > Currently, driver supports CQE based TX p
On Thu, 2020-12-03 at 18:29 -0800, Jakub Kicinski wrote:
> On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> > Add TX PTP port object support for better TX timestamping accuracy.
> > Currently, driver supports CQE based TX port timestamp. Device
> > also offers TX port timestamp, which has
On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> Add TX PTP port object support for better TX timestamping accuracy.
> Currently, driver supports CQE based TX port timestamp. Device
> also offers TX port timestamp, which has less jitter and better
> reflects the actual time of a packet's t
From: Eran Ben Elisha
Add TX PTP port object support for better TX timestamping accuracy.
Currently, driver supports CQE based TX port timestamp. Device
also offers TX port timestamp, which has less jitter and better
reflects the actual time of a packet's transmit.
Define new driver layout calle
26 matches
Mail list logo
