netgraph/ng_source: Switch queuing framework

[donner]

Summary

@glebius requested to change the queuing framework from ifq to mbufq.

[donner]

sys/netgraph/ng_source.c

287

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

[donner]

• Add initializer

[kp]

sys/netgraph/ng_source.c

806

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

[donner]

sys/netgraph/ng_source.c

806

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.

[kp]

Approved by: kp (mentor)

sys/netgraph/ng_source.c

806

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

[donner]

sys/netgraph/ng_source.c

806

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]

• Explain, why it's safe to ignore the error code.

[donner]

sys/netgraph/ng_source.c

806

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

[kp]

sys/netgraph/ng_source.c

806

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

[donner]

• Make assumption explicit.

[kp]

Approved by: kp (mentor)