Page MenuHomeFreeBSD

netgraph/ng_source: Switch queuing framework
ClosedPublic

Authored by donner on Jan 28 2021, 10:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 18 2024, 12:06 AM
Unknown Object (File)
Jan 17 2024, 6:25 AM
Unknown Object (File)
Dec 23 2023, 12:19 PM
Unknown Object (File)
Nov 30 2023, 4:18 AM
Unknown Object (File)
Nov 27 2023, 7:51 PM
Unknown Object (File)
Oct 12 2023, 12:51 AM
Unknown Object (File)
Sep 8 2023, 1:09 PM
Unknown Object (File)
Sep 7 2023, 6:58 AM

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 36600
Build 33489: arc lint + arc unit

Event Timeline

donner retitled this revision from netgraph/ng_sourche: Switch queuing framework to netgraph/ng_source: Switch queuing framework.Jan 28 2021, 10:17 PM
donner added inline comments.
sys/netgraph/ng_source.c
287

Is there a common idiom for that?
Do I need to initialize the mbufq?

This revision is now accepted and ready to land.Jan 29 2021, 5:33 AM
sys/netgraph/ng_source.c
805–812

Can't this hit the limit if another thread is doing ng_source_rcvdata() at the same time?

donner added inline comments.
sys/netgraph/ng_source.c
805–812

Usually the node is used in the mode "learn" or "send" exclusively. It's a debugging tool.

You are right, in principle there is the opportunity that new learned packets are inserted to the queue after the send routine here dequeued the packet. But it's only possible to add a single packet (because the queue is full), so the send function will try to re-add a single packet to a full queue but failed. So we end up with a modified list of packets in the queue, because existing and newly learned packets mix. But this is expected behavior.

Only in the case of mbufq_prepend the mbufq logic will not check the limits, so the queue can go up unlimited. This requires memory pressure (ENOBUFS).

In short: I do not see a problem here.

Approved by: kp (mentor)

sys/netgraph/ng_source.c
805–812

Okay. I wonder if it's worth adding a KASSERT() here, especially as we'd leak the mbuf if the enqueue fails.

donner added inline comments.
sys/netgraph/ng_source.c
805–812

That's a serious point. the semantics of mbufq_enqueue differs from _IF_ENQUEUE in this aspect, so the case needs to be handled explicitly.

donner marked an inline comment as done.
  • Explain, why it's safe to ignore the error code.
This revision now requires review to proceed.Jan 29 2021, 10:37 AM
sys/netgraph/ng_source.c
805–812

Forget it. This is a callout, which is always executed under a WRITER lock. So there is no interference possible. I'll document it.

sys/netgraph/ng_source.c
805–812

The KASSERT is an excellent way of documenting that it's impossible (and verifying assumption) :)

  • Make assumption explicit.

Approved by: kp (mentor)

This revision is now accepted and ready to land.Jan 29 2021, 11:08 AM
This revision was automatically updated to reflect the committed changes.