[Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices

[Jan Kiszka]

Miguel Di Ciurcio Filho wrote:
> On Fri, Jul 16, 2010 at 3:34 AM, Jan Kiszka <address@hidden> wrote:
>>> - When using virtio-net, I'm not sure how to handle iovec when vnet_hdr=on
>> Let the sending peer report (offset field or callback) where to find the
>> payload in a frame.
>>
> 
> Looking further, do you mean what net.c:vc_sendv_compat() does?

No. This is for converting vectored into single-buffer requests in case
the network client supports only the latter interface.

My proposal is to let net.c ask the sending peer to point to the payload
inside the frame, either by picking up some VLANClientState::dump_offset
(the peer would have to set during init) or invoking a new callback
function in NetClientInfo.

> 
>> That channel - or a separate one - could also be used to detect if a
>> peer supports dumping at all (vhost...). Then no peer code need to be
>> extended with dump management code, all could be moved into net.c
>>
> 
> What do you mean by channel? (sorry, I'm kinda new around here :-)

Channel was meant in an abstract way. Think of a flag in VLANClientState
that indicates if dumping is supported by the backend. Should be set
during initialization once the operation mode is decided. Or set
VLANClientState::dump_offset to -1 to indicate "nothing to dump here".

> I don't see how to put everything into net.c. Options parsing/setting
> go inside each backend that adds a NetClientDump instance (just a few
> lines as seen in my patch on net/tap.c as example), and when packets
> come through net.c (qemu_deliver_packet_*()) we get them, right?

What speaks against parsing and processing generic netdev options in net.c?

Jan

signature.asc
Description: OpenPGP digital signature