On 07/27/2015 06:03 PM, Yang Hongyang wrote:
On 07/27/2015 05:16 PM, Jason Wang wrote:
[...]
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.
But checking return value is rather simpler than a new netdev type,
isn't it?
But how to implement a plugin which suppose to do the actual work on
the packets?
Well, the filter get the packets, so it can do everything it wants.
how to configure params related to the plugin? different
plugins may need different params, implement as another netdev?
I belive qmp can do this? something like -filter dump,id=f0,len=10000?
So you mean implement another object filter?
Yes.
and the structure is like netdev?
No, it is embedded in netdev.
Ah, I see what you mean, thank you for the patience...
does the command line looks like:
-filter dump,id=f0,len=10000
-netdev tap,XXX,filter=dump
If I need both dump and packets buffering, how will the qmp be?
-filter dump,id=f0,len=10000
-filter buffer,XXX
-netdev tap,XXX,filter=dump:buffer:XXX ?
This is ok but we have several choices, e.g you may want to have a next
field like:
- filter buffer,id=f0
- filter dump,id=f1,len=1000,next=f0
- netdev tap,XXX,filter_root=f1
or
-netdev tap,id=bn0,XXX
-filter dump,id=f0,len=10000,netdev=bn0
-filter buffer,XXX,netdev=bn0 ?
And do you care if we add a filter list to NetClientInfo?
I don't care, and in fact this also shows great advantages over the
proposal of new netdevs. In that case, if you want two filters, two
netdevs is needed and I can't image how to handle offloads or link
status in this case.
and modify the generic layer to deal with these filters?
E.g, init/cleanup filters, go through these filters, check
for return values, stop call peer's receiving.
I think it's ok to do these. What we really need is an new layer before
peer's receiving not new kinds of netdevs.
This is our main concern at the beginning, we want to avoid
modify the netdev generic layer too much, and do all things
within the filter dev so that this could be a bolt-on
feature. But if you don't care about this, we could simply
implement it as you said.
I don't think much will be modified. Maybe just add callbacks on
receive, initialization and cleanup. Most of the codes should be limited
to filter itself. The point is 'filter' is not a kind of device or
backend, so most of the fields will be unnecessary. Treating it as
pseudo netdev will bring burdens too. E.g: dealing with vnet headers,
offloads, be/le setting and link status and probably even more.