Hi:
Several questions:
- Looks like we can do more than filter, so may be something like
traffic control or other is more suitable?

The filter is just a transparent proxy of a backend if no filter plugin
is inserted. It just by pass all packets. Capture all traffic is the
purpose
of the filter. As long as we have an entry to capture all packets, we
can do more, this is what a filter plugin will do. There are some use
cases
I can think of:
- dump, by using filter, we can dump either output/input packets.
- buffer, to buffer/release packets, this feature can be used when using
macrocheckpoing. Or other Remus like VM FT solutions. You can
also supply an interval to a buffer plugin, which will release
packets by interval.

This sounds like traffic shaping.

May be other use cases based on this special backend.

- What's the advantages of introducing a new type of netdev? As far as I
can see, just replace the dump function in Tomas' series with a
configurable function pointer will do the trick? (Probably with some
monitor commands). And then you won't even need to deal with vnet hder
and offload stuffs?

I think dump function focus on every netdev, it adds an dump_enabled to
NetClientState, and dump the packet when the netdev receive been called,
This filter function more focus on packets between backend/frontend,
it's kind of an injection to the network packets flow.
So the semantics are different I think.

Yes, their functions are different. But the packet paths are similar,
both require the packets go through themselves before reaching the
peers. So simply passing the packets to the filter function before
calling nc->info->receive{_raw}() in qemu_deliver_packet() will also work?

I think this won't work for the buffer case? If we want the buffer case
to work under this, we should modify the generic netdev layer code, to
check the return value of the filter function call. And it is not as
extensible as we abstract the filter function to a netdev, We can
flexibly add/remove/change filter plugins on the fly.