Re: IFF_OACTIVE -- is it still relevant?

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 21, 2020, at 6:47 PM, Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost> wrote:
> 
> I agree.
> I think the OACTIVE bool field can also be moved to struct ifaltq and
> protected by ifaltq::ifq_lock.  Using ifaltq::ifq_lock to protect the
> bool field would not increase lock contention, as IFQ_ENQUEUE and
> IFQ_DEQUEUE already uses ifaltq::ifq_lock.

Ok, fair enough... However, I won't be using any lock for it... if anything, the lock that covers it would be the lock protecting the driver's hardware-managed transmit queue (which is managed independently of the output queue between the network interface and the upper layers of the stack); it's an indicator of those hardware queue resources being exhausted, after all.  It's really just an optimization, and so I think I'll use a 32-bit word and manipulate it with atomic_{load,store}_relaxed().

-- thorpej