Frame Preemption is one of the core standards of TSN. It enables
low latency trasmission of time-critical frames by allowing them to
interrupt the transmission of other non time-critical traffic. Frame
preemption is only active when the link partner is also capable of it.
This negotiation is done using LLDP as specified by the standard. Open
source lldp utilities and other applications, can make use of
the ioctls and the header being here, to query preemption capabilities
and configure various parameters.
Pranavi Somisetty (2):
include: uapi: Add new ioctl definitions to support Frame Preemption
include: uapi: Add Frame preemption parameters
include/uapi/linux/preemption_8023br.h | 30 ++++++++++++++++++++++++++
include/uapi/linux/sockios.h | 6 ++++++
net/core/dev_ioctl.c | 6 +++++-
3 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/linux/preemption_8023br.h
--
2.36.1
Hi Pranavi,
On Thu, Nov 03, 2022 at 05:33:46AM -0600, Pranavi Somisetty wrote:
> Frame Preemption is one of the core standards of TSN. It enables
> low latency trasmission of time-critical frames by allowing them to
> interrupt the transmission of other non time-critical traffic. Frame
> preemption is only active when the link partner is also capable of it.
> This negotiation is done using LLDP as specified by the standard. Open
> source lldp utilities and other applications, can make use of
> the ioctls and the header being here, to query preemption capabilities
> and configure various parameters.
>
> Pranavi Somisetty (2):
> include: uapi: Add new ioctl definitions to support Frame Preemption
> include: uapi: Add Frame preemption parameters
>
> include/uapi/linux/preemption_8023br.h | 30 ++++++++++++++++++++++++++
> include/uapi/linux/sockios.h | 6 ++++++
> net/core/dev_ioctl.c | 6 +++++-
> 3 files changed, 41 insertions(+), 1 deletion(-)
> create mode 100644 include/uapi/linux/preemption_8023br.h
>
> --
> 2.36.1
>
Have you seen:
https://patchwork.kernel.org/project/netdevbpf/cover/[email protected]/
> -----Original Message-----
> From: Vladimir Oltean <[email protected]>
> Sent: Friday, November 4, 2022 4:21 AM
> To: Somisetty, Pranavi <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; git (AMD-Xilinx) <[email protected]>; Katakam, Harini
> <[email protected]>; Pandey, Radhey Shyam
> <[email protected]>; Simek, Michal
> <[email protected]>; [email protected];
> [email protected]
> Subject: Re: [RFC PATCH net-next 0/2] Add support for Frame preemption
> (IEEE
>
> Hi Pranavi,
>
> On Thu, Nov 03, 2022 at 05:33:46AM -0600, Pranavi Somisetty wrote:
> > Frame Preemption is one of the core standards of TSN. It enables low
> > latency trasmission of time-critical frames by allowing them to
> > interrupt the transmission of other non time-critical traffic. Frame
> > preemption is only active when the link partner is also capable of it.
> > This negotiation is done using LLDP as specified by the standard. Open
> > source lldp utilities and other applications, can make use of the
> > ioctls and the header being here, to query preemption capabilities and
> > configure various parameters.
> >
> > Pranavi Somisetty (2):
> > include: uapi: Add new ioctl definitions to support Frame Preemption
> > include: uapi: Add Frame preemption parameters
> >
> > include/uapi/linux/preemption_8023br.h | 30
> ++++++++++++++++++++++++++
> > include/uapi/linux/sockios.h | 6 ++++++
> > net/core/dev_ioctl.c | 6 +++++-
> > 3 files changed, 41 insertions(+), 1 deletion(-) create mode 100644
> > include/uapi/linux/preemption_8023br.h
> >
> > --
> > 2.36.1
> >
>
> Have you seen:
> https://patchwork.kernel.org/project/netdevbpf/cover/20220816222920.195
> [email protected]/
Thanks Vladimir, I hadn't, we will try to use your RFC.
Regards
Pranavi
On Fri, Nov 04, 2022 at 02:08:25PM +0000, Somisetty, Pranavi wrote:
> > Have you seen:
> > https://patchwork.kernel.org/project/netdevbpf/cover/20220816222920.195
> > [email protected]/
>
> Thanks Vladimir, I hadn't, we will try to use your RFC.
The point is not to *use* it (you can't even without some major effort -
I didn't even publish the user space patches, even though I have ethtool
ready and openlldp almost completely ready as well; plus I also did some
more rework to the posted RFC, which I didn't repost yet).
The point is that the RFC has stalled due to seemingly no clear answers
to some fundamental questions about the placement of these new features.
It would be good if some extra feedback from people familiar with frame
preemption/MAC merge could be provided there.
Thanks.