* packet deadline and process scheduling
@ 2020-08-28 6:45 S.V.R.Anand
2020-08-28 8:14 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: S.V.R.Anand @ 2020-08-28 6:45 UTC (permalink / raw)
To: netdev
Hi,
In the control loop application I am trying to build, an incoming message from
the network will have a deadline before which it should be delivered to the
receiver process. This essentially calls for a way of scheduling this process
based on the deadline information contained in the message.
If not already available, I wish to write code for such run-time ordering of
processes in the earlist deadline first fashion. The assumption, however
futuristic it may be, is that deadline information is contained as part of the
packet header something like an inband-OAM.
Your feedback on the above will be very helpful.
Hope the above objective will be of general interest to netdev as well.
My apologies if this is not the appropriate mailing list for posting this kind
of mails.
Anand
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: packet deadline and process scheduling
2020-08-28 6:45 packet deadline and process scheduling S.V.R.Anand
@ 2020-08-28 8:14 ` Eric Dumazet
2020-08-28 8:50 ` S.V.R.Anand
0 siblings, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2020-08-28 8:14 UTC (permalink / raw)
To: S.V.R.Anand, netdev
On 8/27/20 11:45 PM, S.V.R.Anand wrote:
> Hi,
>
> In the control loop application I am trying to build, an incoming message from
> the network will have a deadline before which it should be delivered to the
> receiver process. This essentially calls for a way of scheduling this process
> based on the deadline information contained in the message.
>
> If not already available, I wish to write code for such run-time ordering of
> processes in the earlist deadline first fashion. The assumption, however
> futuristic it may be, is that deadline information is contained as part of the
> packet header something like an inband-OAM.
>
> Your feedback on the above will be very helpful.
>
> Hope the above objective will be of general interest to netdev as well.
>
> My apologies if this is not the appropriate mailing list for posting this kind
> of mails.
>
> Anand
>
Is this described in some RFC ?
If not, I guess you might have to code this in user space.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: packet deadline and process scheduling
2020-08-28 8:14 ` Eric Dumazet
@ 2020-08-28 8:50 ` S.V.R.Anand
2020-08-28 14:01 ` Willem de Bruijn
0 siblings, 1 reply; 6+ messages in thread
From: S.V.R.Anand @ 2020-08-28 8:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
There is an active Internet draft "Packet Delivery Deadline time in
6LoWPAN Routing Header"
(https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which
is presently in the RFC Editor queue and is expected to become an RFC in
the near future. I happened to be one of the co-authors of this draft.
The main objective of the draft is to support time sensitive industrial
applications such as Industrial process control and automation over IP
networks. While the current draft caters to 6LoWPAN networks, I would
assume that it can be extended to carry deadline information in other
encapsulations including IPv6.
Once the packet reaches the destination at the network stack in the
kernel, it has to be passed on to the receiver application within the
deadline carried in the packet because it is the receiver application
running in user space is the eventual consumer of the data. My mail below is for
ensuring passing on the packet sitting in the socket interface to the
user receiver application process in a timely fashion with the help of
OS scheduler. Since the incoming packet experieces variable delay, the
remaining time left before deadline approaches too varies. There should
be a mechanism within the kernel, where network stack needs to
communicate with the OS scheduler by letting the scheduler know the
deadline before user application socket recv call is expected to return.
Anand
On 20-08-28 10:14:13, Eric Dumazet wrote:
>
>
> On 8/27/20 11:45 PM, S.V.R.Anand wrote:
> > Hi,
> >
> > In the control loop application I am trying to build, an incoming message from
> > the network will have a deadline before which it should be delivered to the
> > receiver process. This essentially calls for a way of scheduling this process
> > based on the deadline information contained in the message.
> >
> > If not already available, I wish to write code for such run-time ordering of
> > processes in the earlist deadline first fashion. The assumption, however
> > futuristic it may be, is that deadline information is contained as part of the
> > packet header something like an inband-OAM.
> >
> > Your feedback on the above will be very helpful.
> >
> > Hope the above objective will be of general interest to netdev as well.
> >
> > My apologies if this is not the appropriate mailing list for posting this kind
> > of mails.
> >
> > Anand
> >
>
> Is this described in some RFC ?
>
> If not, I guess you might have to code this in user space.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: packet deadline and process scheduling
2020-08-28 8:50 ` S.V.R.Anand
@ 2020-08-28 14:01 ` Willem de Bruijn
2020-08-28 20:45 ` Stephen Hemminger
2020-08-29 9:37 ` S.V.R.Anand
0 siblings, 2 replies; 6+ messages in thread
From: Willem de Bruijn @ 2020-08-28 14:01 UTC (permalink / raw)
To: S.V.R.Anand; +Cc: Eric Dumazet, Network Development
On Fri, Aug 28, 2020 at 10:51 AM S.V.R.Anand <anandsvr@iisc.ac.in> wrote:
>
> There is an active Internet draft "Packet Delivery Deadline time in
> 6LoWPAN Routing Header"
> (https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which
> is presently in the RFC Editor queue and is expected to become an RFC in
> the near future. I happened to be one of the co-authors of this draft.
> The main objective of the draft is to support time sensitive industrial
> applications such as Industrial process control and automation over IP
> networks. While the current draft caters to 6LoWPAN networks, I would
> assume that it can be extended to carry deadline information in other
> encapsulations including IPv6.
>
> Once the packet reaches the destination at the network stack in the
> kernel, it has to be passed on to the receiver application within the
> deadline carried in the packet because it is the receiver application
> running in user space is the eventual consumer of the data. My mail below is for
> ensuring passing on the packet sitting in the socket interface to the
> user receiver application process in a timely fashion with the help of
> OS scheduler. Since the incoming packet experieces variable delay, the
> remaining time left before deadline approaches too varies. There should
> be a mechanism within the kernel, where network stack needs to
> communicate with the OS scheduler by letting the scheduler know the
> deadline before user application socket recv call is expected to return.
>
> Anand
>
>
> On 20-08-28 10:14:13, Eric Dumazet wrote:
> >
> >
> > On 8/27/20 11:45 PM, S.V.R.Anand wrote:
> > > Hi,
> > >
> > > In the control loop application I am trying to build, an incoming message from
> > > the network will have a deadline before which it should be delivered to the
> > > receiver process. This essentially calls for a way of scheduling this process
> > > based on the deadline information contained in the message.
> > >
> > > If not already available, I wish to write code for such run-time ordering of
> > > processes in the earlist deadline first fashion. The assumption, however
> > > futuristic it may be, is that deadline information is contained as part of the
> > > packet header something like an inband-OAM.
> > >
> > > Your feedback on the above will be very helpful.
> > >
> > > Hope the above objective will be of general interest to netdev as well.
> > >
> > > My apologies if this is not the appropriate mailing list for posting this kind
> > > of mails.
> > >
> > > Anand
> > >
> >
> > Is this described in some RFC ?
> >
> > If not, I guess you might have to code this in user space.
Could ingress redirect to an IFB device with FQ scheduler work for
ingress EDT? With a BPF program at ifb device egress hook to read
the header and write skb->tstamp.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: packet deadline and process scheduling
2020-08-28 14:01 ` Willem de Bruijn
@ 2020-08-28 20:45 ` Stephen Hemminger
2020-08-29 9:37 ` S.V.R.Anand
1 sibling, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2020-08-28 20:45 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: S.V.R.Anand, Eric Dumazet, Network Development
On Fri, 28 Aug 2020 16:01:31 +0200
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> On Fri, Aug 28, 2020 at 10:51 AM S.V.R.Anand <anandsvr@iisc.ac.in> wrote:
> >
> > There is an active Internet draft "Packet Delivery Deadline time in
> > 6LoWPAN Routing Header"
> > (https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which
> > is presently in the RFC Editor queue and is expected to become an RFC in
> > the near future. I happened to be one of the co-authors of this draft.
> > The main objective of the draft is to support time sensitive industrial
> > applications such as Industrial process control and automation over IP
> > networks. While the current draft caters to 6LoWPAN networks, I would
> > assume that it can be extended to carry deadline information in other
> > encapsulations including IPv6.
> >
> > Once the packet reaches the destination at the network stack in the
> > kernel, it has to be passed on to the receiver application within the
> > deadline carried in the packet because it is the receiver application
> > running in user space is the eventual consumer of the data. My mail below is for
> > ensuring passing on the packet sitting in the socket interface to the
> > user receiver application process in a timely fashion with the help of
> > OS scheduler. Since the incoming packet experieces variable delay, the
> > remaining time left before deadline approaches too varies. There should
> > be a mechanism within the kernel, where network stack needs to
> > communicate with the OS scheduler by letting the scheduler know the
> > deadline before user application socket recv call is expected to return.
> >
> > Anand
> >
> >
> > On 20-08-28 10:14:13, Eric Dumazet wrote:
> > >
> > >
> > > On 8/27/20 11:45 PM, S.V.R.Anand wrote:
> > > > Hi,
> > > >
> > > > In the control loop application I am trying to build, an incoming message from
> > > > the network will have a deadline before which it should be delivered to the
> > > > receiver process. This essentially calls for a way of scheduling this process
> > > > based on the deadline information contained in the message.
> > > >
> > > > If not already available, I wish to write code for such run-time ordering of
> > > > processes in the earlist deadline first fashion. The assumption, however
> > > > futuristic it may be, is that deadline information is contained as part of the
> > > > packet header something like an inband-OAM.
> > > >
> > > > Your feedback on the above will be very helpful.
> > > >
> > > > Hope the above objective will be of general interest to netdev as well.
> > > >
> > > > My apologies if this is not the appropriate mailing list for posting this kind
> > > > of mails.
> > > >
> > > > Anand
> > > >
> > >
> > > Is this described in some RFC ?
> > >
> > > If not, I guess you might have to code this in user space.
>
> Could ingress redirect to an IFB device with FQ scheduler work for
> ingress EDT? With a BPF program at ifb device egress hook to read
> the header and write skb->tstamp.
This might be an attack vector for remote DOS. If you believe all messages
it might be possible to create huge set of messages all of which have to be
processed at once.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: packet deadline and process scheduling
2020-08-28 14:01 ` Willem de Bruijn
2020-08-28 20:45 ` Stephen Hemminger
@ 2020-08-29 9:37 ` S.V.R.Anand
1 sibling, 0 replies; 6+ messages in thread
From: S.V.R.Anand @ 2020-08-29 9:37 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Eric Dumazet, Network Development
Thanks a lot for the suggestion. If my understanding is correct, I think
it solves part of the problem by dequeueing packets with deadline in a
timely manner using bpf and FQ scheduler combination. Let me know if my
understanding is correct. Once the packets are dequeued, how about
scheduling of the receiver application process running in the user space in
a timely manner before the packet deadline ? By doing this, we are
ensuring timely delivery of the data to the receiver application.
Anand
On 20-08-28 16:01:31, Willem de Bruijn wrote:
>
>
> On Fri, Aug 28, 2020 at 10:51 AM S.V.R.Anand <anandsvr@iisc.ac.in> wrote:
> >
> > There is an active Internet draft "Packet Delivery Deadline time in
> > 6LoWPAN Routing Header"
> > (https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/) which
> > is presently in the RFC Editor queue and is expected to become an RFC in
> > the near future. I happened to be one of the co-authors of this draft.
> > The main objective of the draft is to support time sensitive industrial
> > applications such as Industrial process control and automation over IP
> > networks. While the current draft caters to 6LoWPAN networks, I would
> > assume that it can be extended to carry deadline information in other
> > encapsulations including IPv6.
> >
> > Once the packet reaches the destination at the network stack in the
> > kernel, it has to be passed on to the receiver application within the
> > deadline carried in the packet because it is the receiver application
> > running in user space is the eventual consumer of the data. My mail below is for
> > ensuring passing on the packet sitting in the socket interface to the
> > user receiver application process in a timely fashion with the help of
> > OS scheduler. Since the incoming packet experieces variable delay, the
> > remaining time left before deadline approaches too varies. There should
> > be a mechanism within the kernel, where network stack needs to
> > communicate with the OS scheduler by letting the scheduler know the
> > deadline before user application socket recv call is expected to return.
> >
> > Anand
> >
> >
> > On 20-08-28 10:14:13, Eric Dumazet wrote:
> > >
> > >
> > > On 8/27/20 11:45 PM, S.V.R.Anand wrote:
> > > > Hi,
> > > >
> > > > In the control loop application I am trying to build, an incoming message from
> > > > the network will have a deadline before which it should be delivered to the
> > > > receiver process. This essentially calls for a way of scheduling this process
> > > > based on the deadline information contained in the message.
> > > >
> > > > If not already available, I wish to write code for such run-time ordering of
> > > > processes in the earlist deadline first fashion. The assumption, however
> > > > futuristic it may be, is that deadline information is contained as part of the
> > > > packet header something like an inband-OAM.
> > > >
> > > > Your feedback on the above will be very helpful.
> > > >
> > > > Hope the above objective will be of general interest to netdev as well.
> > > >
> > > > My apologies if this is not the appropriate mailing list for posting this kind
> > > > of mails.
> > > >
> > > > Anand
> > > >
> > >
> > > Is this described in some RFC ?
> > >
> > > If not, I guess you might have to code this in user space.
>
> Could ingress redirect to an IFB device with FQ scheduler work for
> ingress EDT? With a BPF program at ifb device egress hook to read
> the header and write skb->tstamp.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-08-29 9:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-28 6:45 packet deadline and process scheduling S.V.R.Anand
2020-08-28 8:14 ` Eric Dumazet
2020-08-28 8:50 ` S.V.R.Anand
2020-08-28 14:01 ` Willem de Bruijn
2020-08-28 20:45 ` Stephen Hemminger
2020-08-29 9:37 ` S.V.R.Anand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).