|
Max Timchenko
|
Should an io-pkt driver call its _start function in transmission complete interrupt?
|
|
Max Timchenko
02/27/2011 9:15 AM
post83559
|
Should an io-pkt driver call its _start function in transmission complete interrupt?
Dear forum,
altq(9) [1] manual says: "A driver is supposed to call if_start() from transmission complete interrupts in order to
trigger the next dequeue."
In our driver (or any driver), there's a possibility TX can not be done right now (no buffer descriptors etc.) and then
the networking stack will call us again sometime to retry.
Should a driver call its own start() function on receiving a transmission complete interrupt to dequeue and process the
next available packet, or should it wait for the stack to decide when to call the driver's start() the next time?
Thanks,
Max
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=altq
|
|
|
|
|
|
Hugh Brown
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
|
|
Hugh Brown
02/28/2011 7:56 AM
post83567
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
As a rule, we don¹t enable transmit complete interrupts in our drivers.
There are 2 ways to reap transmitted packets from the driver, by either
reaping completed packets on the next transmit operation or by scheduling a
1 second timer that calls the transmit reap routine.
On 11-02-27 9:16 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
> Dear forum,
>
> altq(9) [1] manual says: "A driver is supposed to call if_start() from
> transmission complete interrupts in order to trigger the next dequeue."
>
> In our driver (or any driver), there's a possibility TX can not be done right
> now (no buffer descriptors etc.) and then the networking stack will call us
> again sometime to retry.
>
> Should a driver call its own start() function on receiving a transmission
> complete interrupt to dequeue and process the next available packet, or should
> it wait for the stack to decide when to call the driver's start() the next
> time?
>
> Thanks,
> Max
>
> [1] http://www.openbsd.org/cgi-bin/man.cgi?query=altq
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83559
>
>
--
Hugh Brown (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
|
|
|
|
|
|
Max Timchenko
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
|
|
Max Timchenko
03/06/2011 3:13 AM
post83777
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
Hi Hugh,
> As a rule, we don¹t enable transmit complete interrupts in our drivers.
> There are 2 ways to reap transmitted packets from the driver, by either
> reaping completed packets on the next transmit operation or by scheduling a
> 1 second timer that calls the transmit reap routine.
My reason for the question is not to reap transmitted packets, but to retry a previous transmit that failed due to lack
of buffers for example - I've noticed that the stack seems to not call the driver back on its own until another packet
is transmitted to the stack.
In case of low-rate UDP packets, for example, if one packet was not transmitted because of lack of buffers it will not
get retried until the next packet is sent to the stack, which can be a while.
|
|
|
|
|
|
Hugh Brown
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
|
|
Hugh Brown
03/07/2011 8:02 AM
post83783
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
I’m no TCP expert, but AFAIK it is up to the application sending the UDP
packets that must implement re-transmission. I don’t know of any way to
“kick” the stack to make it re-transmit a packet. Maybe somebody with more
TCP/UDP experience can answer this.
On 11-03-06 3:14 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
> Hi Hugh,
>
>> > As a rule, we don¹t enable transmit complete interrupts in our drivers.
>> > There are 2 ways to reap transmitted packets from the driver, by either
>> > reaping completed packets on the next transmit operation or by scheduling a
>> > 1 second timer that calls the transmit reap routine.
>
> My reason for the question is not to reap transmitted packets, but to retry a
> previous transmit that failed due to lack of buffers for example - I've
> noticed that the stack seems to not call the driver back on its own until
> another packet is transmitted to the stack.
>
> In case of low-rate UDP packets, for example, if one packet was not
> transmitted because of lack of buffers it will not get retried until the next
> packet is sent to the stack, which can be a while.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83777
>
--
Hugh Brown (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
|
|
|
|
|
|
Max Timchenko
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
|
|
Max Timchenko
03/07/2011 9:41 AM
post83785
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
> I’m no TCP expert, but AFAIK it is up to the application sending the UDP
> packets that must implement re-transmission. I don’t know of any way to
> “kick” the stack to make it re-transmit a packet. Maybe somebody with more
> TCP/UDP experience can answer this.
The discussion is on the io-pkt level, below TCP/IP - we're dealing with Ethernet frames stored in mbufs and queued for
transmission. If a stack calls the driver's start() handler and the driver does not dequeue a mbuf, what happens to the
mbuf?
Your reply can be understood to mean the network stack will discard the mbuf if the driver does not accept it, thus
dropping the frame with the UDP/TCP packet contained in it - is that correct, or will the network stack keep the mbuf in
the interface's queue and try to give it to the driver on the next call to its start() handler?
And, if the mbuf is saved, what is the event that causes the io-pkt to call the driver's start() handler again? My
current guess is there's no timer and only a transmission of another packet by the application will cause the stack to
call the driver's start() handler.
Thanks for your patience,
Max
|
|
|
|
|
|
Hugh Brown
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
|
|
Hugh Brown
03/07/2011 10:49 AM
post83791
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
Which network driver are you using?
On 11-03-07 9:41 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
>> > I¹m no TCP expert, but AFAIK it is up to the application sending the UDP
>> > packets that must implement re-transmission. I don¹t know of any way to
>> > ³kick² the stack to make it re-transmit a packet. Maybe somebody with more
>> > TCP/UDP experience can answer this.
>
> The discussion is on the io-pkt level, below TCP/IP - we're dealing with
> Ethernet frames stored in mbufs and queued for transmission. If a stack calls
> the driver's start() handler and the driver does not dequeue a mbuf, what
> happens to the mbuf?
>
> Your reply can be understood to mean the network stack will discard the mbuf
> if the driver does not accept it, thus dropping the frame with the UDP/TCP
> packet contained in it - is that correct, or will the network stack keep the
> mbuf in the interface's queue and try to give it to the driver on the next
> call to its start() handler?
>
> And, if the mbuf is saved, what is the event that causes the io-pkt to call
> the driver's start() handler again? My current guess is there's no timer and
> only a transmission of another packet by the application will cause the stack
> to call the driver's start() handler.
>
> Thanks for your patience,
> Max
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83785
>
--
Hugh Brown (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
|
|
|
|
|
|
Max Timchenko
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
|
|
Max Timchenko
03/07/2011 11:00 AM
post83792
|
Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
> Which network driver are you using?
I'm writing a new one. This question could be of interest to anyone adding a new network driver to QNX...
(if you want to know about the specific project, ask Fred Plante)
Thanks,
Max
|
|
|
|
|
|
Hugh Brown
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
|
|
Hugh Brown
03/07/2011 11:04 AM
post83793
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
Heres the response I got from our stack expert.
There's two levels here: the if_snd Q and then the driver.
If the if_start() callout returns without emptying the Q,
presumably the driver is out of resources. What happens
next depends on the driver. If it does nothing, then
yes we will only call the if_start() callout on next packet.
If it looks for a tx done interrupt or something it may
poke itself into action. This is what the ifp->if_flags_tx
IFF_OACTIVE flag is a hint for. It's supposed to mean the
driver is waiting for a tx done interrupt (or something
to wake it up when it will retry tx). While that's set
the stack won't recall the if_start() callout.
On 11-03-07 11:00 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
>> > Which network driver are you using?
>
> I'm writing a new one. This question could be of interest to anyone adding a
> new network driver to QNX...
>
> (if you want to know about the specific project, ask Fred Plante)
>
> Thanks,
> Max
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83792
>
>
--
Hugh Brown (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
|
|
|
|
|
|
Edward Lee
|
RE: Should an io-pkt driver call its _start function in transmission complete interrupt?
|
|
Edward Lee
03/08/2011 8:29 PM
post83837
|
RE: Should an io-pkt driver call its _start function in transmission complete interrupt?
Frame re-transmit is the responsibility of the communication protocol, such as FTP, and not part of the device driver.
If you start to implement re-transmit in the device driver, you may mess up the protocol.
-----Original Message-----
From: Hugh Brown [mailto:community-noreply@qnx.com]
Sent: March-07-11 11:04 AM
To: drivers-networking
Subject: Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
Heres the response I got from our stack expert.
There's two levels here: the if_snd Q and then the driver.
If the if_start() callout returns without emptying the Q,
presumably the driver is out of resources. What happens
next depends on the driver. If it does nothing, then
yes we will only call the if_start() callout on next packet.
If it looks for a tx done interrupt or something it may
poke itself into action. This is what the ifp->if_flags_tx
IFF_OACTIVE flag is a hint for. It's supposed to mean the
driver is waiting for a tx done interrupt (or something
to wake it up when it will retry tx). While that's set
the stack won't recall the if_start() callout.
On 11-03-07 11:00 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
>> > Which network driver are you using?
>
> I'm writing a new one. This question could be of interest to anyone adding a
> new network driver to QNX...
>
> (if you want to know about the specific project, ask Fred Plante)
>
> Thanks,
> Max
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83792
>
>
--
Hugh Brown (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post83793
|
|
|
|
|
|
Sean Boudreau(deleted)
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
|
|
Sean Boudreau(deleted)
03/09/2011 9:40 AM
post83866
|
Re: Should an io-pkt driver call its _start function in transmission
complete interrupt?
This is the means by which the driver flushes out its
tx queue, not a retransmit. Retransmit will happen
as it normally would if the tx queue overflows and a
packet is actually dropped.
-seanb
On Tue, Mar 08, 2011 at 08:29:36PM -0500, Edward Lee wrote:
> Frame re-transmit is the responsibility of the communication protocol, such as FTP, and not part of the device driver.
If you start to implement re-transmit in the device driver, you may mess up the protocol.
>
>
> -----Original Message-----
> From: Hugh Brown [mailto:community-noreply@qnx.com]
> Sent: March-07-11 11:04 AM
> To: drivers-networking
> Subject: Re: Should an io-pkt driver call its _start function in transmission complete interrupt?
>
> Heres the response I got from our stack expert.
>
> There's two levels here: the if_snd Q and then the driver.
> If the if_start() callout returns without emptying the Q,
> presumably the driver is out of resources. What happens
> next depends on the driver. If it does nothing, then
> yes we will only call the if_start() callout on next packet.
> If it looks for a tx done interrupt or something it may
> poke itself into action. This is what the ifp->if_flags_tx
> IFF_OACTIVE flag is a hint for. It's supposed to mean the
> driver is waiting for a tx done interrupt (or something
> to wake it up when it will retry tx). While that's set
> the stack won't recall the if_start() callout.
>
>
> On 11-03-07 11:00 AM, "Max Timchenko" <community-noreply@qnx.com> wrote:
>
> >> > Which network driver are you using?
> >
> > I'm writing a new one. This question could be of interest to anyone adding a
> > new network driver to QNX...
> >
> > (if you want to know about the specific project, ask Fred Plante)
> >
> > Thanks,
> > Max
> >
> >
> >
> > _______________________________________________
> >
> > Networking Drivers
> > http://community.qnx.com/sf/go/post83792
> >
> >
>
> --
> Hugh Brown (613) 591-0931 ext. 2209 (voice)
> QNX Software Systems Ltd. (613) 591-3579 (fax)
> 175 Terence Matthews Cres. email: hsbrown@qnx.com
> Kanata, Ontario, Canada.
> K2M 1W8
>
>
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83793
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post83837
|
|
|
|
|
|
