In D23656#519345, @mjg wrote:

no, keep it grouped with the rest for consistency but #if defined(_KERNEL) around it

Shift down under _KERNEL.

In D23654#519196, @hselasky wrote:

The Mellanox drivers currently manage this internally:
See: https://svnweb.freebsd.org/changeset/base/357294
Usually there are many packets processed per interrupt.

In D23656#519337, @mjg wrote:

looks like this is guarded by _KERNEL in the original header, we should stick to it just in case in the new one

This change looks good to me in general. The only problem I see that Mellanox will now won't have batched epoch. And this was one of the drivers that really benefited from it in our testing of batching epoch at interrupt level.

• Add flag to struct task to mark the task as requiring network epoch.
• Use NET_TASK_INIT() and NET_GROUPTASK_INIT() for drivers that process
• Revert "Temporarily force IFF_NEEDSEPOCH until drivers have been resolved."

Convert pointer in struct task to a flag.

Thanks for the find. I'd rather move the entrance to dyn_tick(). Would use less lines of code and would make it easier to spot it later, when we have callouts supporting epoch.

Since this revision was commandeered, I created a new one: https://reviews.freebsd.org/D23518

Hans, first you start commit war in subversion and then you "commandeer" my revision. We will not make any progress if you "help" like this.

In D23408#513926, @hselasky wrote:

In the kernel there are 403 instances of TASK_INIT(). In this patch I only see NET_TASK_INIT() used 5 times. Does this justify the increased memory usage of "struct task".
grep -r TASK_INIT\( sys/ | grep -v GTASK | wc -l

403

• Add a temporary compatibility hack to ease transition to new ABI
• Bump kernel version.

In D23348#513427, @hselasky wrote:

Can you please point me to broken USB WLANs?

Please read through this patch and you'll see.

In D23348#513064, @hselasky wrote:

Two drivers of many USB WLANs were fixed! And you've left the rest broken. This is not good!

In D23348#513068, @hselasky wrote:

Let me repeat myself about LinuxKPI. The fact that it puts INTR_TYPE_NET on any interrupt is a mistake in LinuxKPI, not in my patch.

I disagree. INTR_TYPE_NET is only an indicator of interrupt thread priority, and should not be bound to network drivers only!

In D23348#512984, @hselasky wrote:

Already many ethernet drivers are almost C&P of each other and putting the EPOCH into the drivers makes sense, because for many older PCI devices, there are many kinds of interrupt sources, like TX completion interrupts, LINK events, and doing the EPOCH for those cases is not needed. Also some drivers use INTR_TYPE_NET which are not network drivers, for example the LinuxKPI.

In D23348#512982, @hselasky wrote:

@glebius: Or do you claim that all these drivers are broken in head and this change is required to fix them?
I claim that many of the drivers I've patched are broken.
Debugnet is broken.
All USB WLAN is broken.

Do you suggest this change as an alternative to D23242? Cause you added epoch in many places where we already are in epoch, for example interrupt handlers and polling handlers. Or do you claim that all these drivers are broken in head and this change is required to fix them?

Minority of drivers need this flag and the future plan is none will need.

Rebase to fresh master.

Rebased to fresh master.

I'd really appreciate some reviewing. I'm going to commit this week.

I'd really appreciate some reviewing. I'm going to commit this week.

Clarify unclear comment.

I see. That's because in next review we may produce multipage slabs with an allocation crossing a boundary.

Why did you convert all mbuf zones to contig? Only jumbo 9k and jumbo 16k really require that.