On 07/27/2015 01:27 PM, Yang Hongyang wrote:
On 07/23/2015 01:59 PM, Jason Wang wrote:
On 07/22/2015 06:55 PM, Yang Hongyang wrote:
This patch add a net filter between network backend and NIC devices.
All packets will pass by this filter.
TODO:
multiqueue support.
plugin support.
+--------------+ +-------------+
+----------+ | filter | |frontend(NIC)|
| real | | | | |
| network <--+backend <-------+ |
| backend | | peer +-------> peer |
+----------+ +--------------+ +-------------+
Usage:
-netdev tap,id=bn0 # you can use whatever backend as needed
-netdev filter,id=f0,backend=bn0,plugin=dump
-device e1000,netdev=f0
Signed-off-by: Yang Hongyang <address@hidden>
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?