From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33762 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZmUd-000870-FN for qemu-devel@nongnu.org; Fri, 16 Jul 2010 11:06:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZmUb-0000fE-SK for qemu-devel@nongnu.org; Fri, 16 Jul 2010 11:06:27 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:54110) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZmUb-0000er-FT for qemu-devel@nongnu.org; Fri, 16 Jul 2010 11:06:25 -0400 Message-ID: <4C40758B.2020901@web.de> Date: Fri, 16 Jul 2010 17:06:51 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1279225380-28790-1-git-send-email-miguel.filho@gmail.com> <4C3FFD88.5020305@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B829762323C4783AB02E81A" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH RFC 0/4] Dumping traffic when using netdev devices List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miguel Di Ciurcio Filho Cc: avi@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B829762323C4783AB02E81A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Miguel Di Ciurcio Filho wrote: > On Fri, Jul 16, 2010 at 3:34 AM, Jan Kiszka wrote: >>> - When using virtio-net, I'm not sure how to handle iovec when vnet_h= dr=3Don >> Let the sending peer report (offset field or callback) where to find t= he >> payload in a frame. >> >=20 > 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. >=20 >> 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 >> >=20 > 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 --------------enig3B829762323C4783AB02E81A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkxAdZAACgkQitSsb3rl5xTXWQCdGbyam6d6nAdZ2Y1s6LLoFqwI fp4AoMZ3BP0+1tUuQJ2AUFDWTZoDq0kH =nGjR -----END PGP SIGNATURE----- --------------enig3B829762323C4783AB02E81A--