From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56046)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1aY3fs-0006pJ-FZ
	for qemu-devel@nongnu.org; Mon, 22 Feb 2016 22:30:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1aY3fn-0006aq-DP
	for qemu-devel@nongnu.org; Mon, 22 Feb 2016 22:30:08 -0500
Received: from mx1.redhat.com ([209.132.183.28]:34901)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1aY3fn-0006am-7S
	for qemu-devel@nongnu.org; Mon, 22 Feb 2016 22:30:03 -0500
References: <cover.1454667697.git.v.maffione@gmail.com>
	<47884767b4d9df94dc2660d1aef7b6124e6d701f.1454667697.git.v.maffione@gmail.com>
	<56C531FD.5080905@redhat.com>
	<CA+_eA9iqKgZWkiVKRcQ6ygF00q8DKLNQF1gg7QopK6KYzgKf=A@mail.gmail.com>
From: Jason Wang <jasowang@redhat.com>
Message-ID: <56CBD228.8010707@redhat.com>
Date: Tue, 23 Feb 2016 11:29:44 +0800
MIME-Version: 1.0
In-Reply-To: <CA+_eA9iqKgZWkiVKRcQ6ygF00q8DKLNQF1gg7QopK6KYzgKf=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] net: netmap: probe netmap interface for
 virtio-net header
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: Giuseppe Lettieri <g.lettieri@iet.unipi.it>, Luigi Rizzo <rizzo@iet.unipi.it>, qemu-devel <qemu-devel@nongnu.org>



On 02/18/2016 09:34 PM, Vincenzo Maffione wrote:
>>>  static void netmap_set_offload(NetClientState *nc, int csum, int tso4, int tso6,
>>> >> @@ -376,7 +394,7 @@ static void netmap_set_offload(NetClientState *nc, int csum, int tso4, int tso6,
>>> >>       * enables the offloadings.
>>> >>       */
>>> >>      if (!s->vnet_hdr_len) {
>>> >> -        netmap_set_vnet_hdr_len(nc, sizeof(struct virtio_net_hdr));
>>> >> +        netmap_do_set_vnet_hdr_len(s, sizeof(struct virtio_net_hdr), true);
>>> >>      }
>>> >>  }
>>> >>
>>> >> @@ -388,7 +406,7 @@ static NetClientInfo net_netmap_info = {
>>> >>      .receive_iov = netmap_receive_iov,
>>> >>      .poll = netmap_poll,
>>> >>      .cleanup = netmap_cleanup,
>>> >> -    .has_ufo = netmap_has_ufo,
>>> >> +    .has_ufo = netmap_has_vnet_hdr,
>> >
>> > This look suspicious, I'm not sure this is correct for netmap. May need
>> > a comment to explain. Usually vnet hdr does not imply ufo.
>> >
>>> >>      .has_vnet_hdr = netmap_has_vnet_hdr,
>>> >>      .has_vnet_hdr_len = netmap_has_vnet_hdr_len,
>>> >>      .using_vnet_hdr = netmap_using_vnet_hdr,
>> >
> Yes, I know it sounds weird in general, but a netmap port using
> virtio-net headers always provides TCPv4, TCPv6, UDP and ECN
> offloadings (done in software inside netmap).
>
> This patch already provides a little comment about UFO support on the
> netmap_has_vnet_hdr() function. 

Just saw that.

> Do you want me to move it here, or is
> the comment not understandable enough?
>
> Thanks for your review,
>   Vincenzo

Nope, it's ok.

Thanks