NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: kern/58168: IFF_OACTIVE semantics and replacement plan is unclear
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
Home |
Main Index |
Thread Index |
Old Index