Re: IFF_OACTIVE -- is it still relevant?

[Greg Troxel <gdt%lexort.com@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

> IFF_OACTIVE is problematic for NET_MPSAFE because it lives in ifnet::if_flags, but needs to be fiddled with when ifnet::if_ioctl_lock is not held.
>
> In some ways, I question the utility of IFF_OACTIVE .. at best, it avoids calling (*if_start)() if there are no transmit slots available... but that situation is something that (*if_start)() routines need to handle anyway.
>
> OpenBSD addressed the issue by making the "output active" indicator an
> independent atomically settable field in the interface queue
> structure, and replacing direct manipulation of IFF_OACTIVE in
> ifnet::if_flags with accessor / mutator functions.  Reporting of
> IFF_OACTIVE to userspace is maintained by returning the traditional
> flag in the ifreq.
>
> I'm not opposed to adopting OpenBSD's approach to fixing this problem, but if we can agree that IFF_OACTIVE is not useful in the first place, then I'd prefer to just rip it out completely.
>
> Thoughts?

My impression is that IFF_OACTIVE has always been an implementation
detail within the network stack.  Traditionally, I would say that
if_start could reliably expect not to be called when IFF_OACTIVE is
true, expecting ether_output to

  add packet to queue
  if ! IFF_OACTIVE
    if_start

and then in the tx complete routine, either queue another packet, or
turn off IFF_OACTIVE.   This is partly from the 4.3/4.4BSD books, and
partly from memory 2.9BSD/4.2BSD era code.

Given all that, it was part of the if_ethersubr/if_foo interface, but if
if_start can't rely on not being called if it's set, then I don't see
the point.

As for exposing it to userland e.g. via flags shown by ifconfig, I would
think that could be removed at any time.

I can see why OpenBSD wanted to preserve traditional behavior; I am
sympathethic to that myself.  But I wonder if there was a functional
reason?