re: kern/58168: IFF_OACTIVE semantics and replacement plan is unclear

[Christoph Badura <bad%bsd.de@localhost>]

The following reply was made to PR kern/58168; it has been noted by GNATS.

From: Christoph Badura <bad%bsd.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: re: kern/58168: IFF_OACTIVE semantics and replacement plan is
 unclear
Date: Sun, 21 Apr 2024 23:38:27 +0200

 I remembered how the IFF_OACTIVE protocol works.
 
 The if_snd queue decouples the "upper half" of the networking stack from
 the "lower half" of the hardware drives that operates in (hardware)
 interrupt context.
 
 Basically the networking stack puts packets for transmission on the if_snd
 queue.  And the interrupt driven output side of driver removes them as
 send buffer space in the hardware becomes available.
 
 The driver sets IFF_OACTIVE whenever it is expecting an interrupt
 signalling the end of processing of a packet to be sent (successfully or
 unsuccessfully e.g. for excessive collisions).  Then it fetches the next
 packet(s) from the if_snd queue and hands it/them over to the hardware,
 expecting more interrupts.
 
 In this manner dequeing packets from the if_snd queue and transmitting
 them is self-clocked by the interrupts from the hardware.
 
 But if there are no more packets queued in the hardware for transmit and
 the if_snd queue is empty this self-clocking stops.  That's when
 IFF_OACTIVE is cleared so that the next call to if_transmit() calls the
 driver's if_start function which enqueues the packet(s) with the hardware
 starting the interrupt driven self-clocking again.
 
 In particular setting IFF_OACTIVE does NOT mean that the interface is
 either unavailable or busy.  And neither is it "up to the driver" to
 define the semantics of IFF_OACTIVE.  This is a generic protocol between
 the upper, interruptless half of the kernel and the lower,
 interrupt-driven half of the drivers.
 
 --chris