From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 20:04:44 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D69452 for ; Tue, 6 Jan 2015 20:04:44 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D8DB2758 for ; Tue, 6 Jan 2015 18:15:05 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so20273wid.6 for ; Tue, 06 Jan 2015 10:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qF6zKavVBwPzGOQ2qEL9vK5M71oQgBlr+dYk1TJJjNQ=; b=F3vWNd4nwCY1U8mTA8pNWMpwVr766g99loJ0Z9giDuuZn+LhAO+AnrNV/wuC899utA 4DtVA4LzuYGmGc9BFa7n+bYLs6v/RWCZfjIH5Sq7E+WrmFrz+ZA74FLDgJen3459tO0q LbUk/j2hqjB2Eipi9hTjpyX9UxIDF+klk9EKe74Je3jk1FOT28r1ntcf+UZzOJq4Byc0 spq7/xYs5iXCBzJOTV8bLXVjv9iYvqBy36rW95aYZE4/m3p5kmwBSlzvgRlHZhRf6IPf JEH0c4tcxSDe09dQ/k/gmiz6VaQBQPMFwL7MqP3//Pw+IoSoByTw76n+V7/HKmyDypAu pviQ== MIME-Version: 1.0 X-Received: by 10.180.20.6 with SMTP id j6mr38670767wie.59.1420568102531; Tue, 06 Jan 2015 10:15:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 10:15:02 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 10:15:02 -0800 X-Google-Sender-Auth: xC_spDNs7VURUjs7ymxYQpEgb7Q Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Adrian Chadd To: Vincenzo Maffione Content-Type: text/plain; charset=UTF-8 Cc: Avinash Sridharan , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:04:44 -0000 On 6 January 2015 at 08:57, Vincenzo Maffione wrote: > 2015-01-06 17:31 GMT+01:00 Avinash Sridharan : >> Hi Vincenzo, >> Thanks for the explanation. From your explanation it seems like the netmap >> in "native" mode over virtio-net should be giving some indication of how >> many extra bytes have been added by the virtio-net driver (or for that >> matter any other driver that provides this type of rx-descriptor). >> Otherwise, the application will have to store knowledge about the specifics >> of the underlying devices which dosen't seem that clean. (I think Adrian was >> referring to the same issue) > > I understand the problem (this was left as an open problem), and it's > not clear to me what should be the best solution. > > On one hand, one could modify the native virtio-net adapter so that it > discards the extra header. This can be done with a copy - as Luigi > suggests - or with some trick involving scatter-gather virtio support > - e.g. trying to make the virtio-net headers go in some other buffers > parallel to the "official" netmap buffers (i.e. the ones your > application reads from). > > On the other end, the virtio-net header carry some information (mainly > TCP/UDP related) that you may not want to discard - even when using > netmap - and this depends on the specific application. > > So to avoid making a one-for-all decision, I thought it was better to > leave it to the application. > >> >> That said, how do we handle TX in this case? Since the underlying driver >> (netmap + virtio-net) expects an extra 12 bytes of header that the >> application should know when to add. Or is this optional? > > Yes you have to add it, otherwise it won't work! It's not optional. In > order to make tests for virtio-net tx, I added a "-H" option to > pkt-gen, which pushes an empty virtio-net-header before the ethernet > frame. You can use "-H 12" for your tests. > > Again, it's not clear (at least to me) how we should manage this > virtio-net peculiarity at the netmap API level. This won't be the first time that there'll be useful data at the front end of an RX mbuf that isn't related to the mbuf payload. It'd be nice if there were something in each rx ring slot saying how far to skip into the buffer to get the beginning of the packet. -adrian