overriding non-NAPI network polling handler with a kernel module

Question

As those familiar with network device drivers are aware, the interface between the kernel and driver has been changed to use NAPI (New API). In this paradigm, a polling function is associated with a napi_struct, which is a new structure that must be allocated by the device driver. At any rate, I have an old driver and don't have the time/will to convert it to NAPI. Since the kernel has been modified to account for NAPI, they use the default function "process_backlog" (/net/core/dev.c) to handle the pre-NAPI functionality. This function is still called within interrupt context on a per packet basis (as opposed to NAPI which polls the queue so it doesnt need interrupted each time). I need to override this function but my problem is that unlike the NAPI poll function that is assigned and created by the device driver, the process_backlog is associated with the per-CPU input queue at boot-time. When I load the module, I can override the method using

   struct softnet_data *queue, backup;
   queue = &__get_cpu_var(softnet_data);
   backup = *queue;
   queue->backlog.poll = my_process_backlog; 

The problem here is that this is only overriding the queue on the CPU that inits the module. Is there some way I can cycle through all the CPU's in a module context? I feel like there has to be some way to do this.

Cheers

Answer 1

That's a really bad idea.

But, if you wanted to set some other per cpu variable, you could use per_cpu(name, cpu).

Update: why is it a bad idea?

Because you're binary patching a part of the core networking code when your driver is loaded. That effects every network driver in the system, not just yours. It's like having a kernel module that replaces the scheduler. If the rest of the kernel was written like that it would never work.

Oh and you remembered to change back to the original process_backlog() when your module is removed right?

If you really think you need to change process_backlog() then you should make the change in the source code and distribute a custom kernel. Or explain the change you need to the upstream networking community and get it accepted upstream.

Or probably better still just convert your driver to NAPI, it's not that hard.