Re: IFF_OACTIVE -- is it still relevant?

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2020/01/22 12:47, Jason Thorpe wrote:
> > 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().

Ah, you are right.  The bool field is not required any lock, sorry.
Indeed, atomic_{load,store}_relaxd() are sufficient for it.


Thanks,

--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>