From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com
 [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id B15038E76
 for <dev@dpdk.org>; Mon, 19 Oct 2015 19:19:24 +0200 (CEST)
Received: by pabrc13 with SMTP id rc13so196549640pab.0
 for <dev@dpdk.org>; Mon, 19 Oct 2015 10:19:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=lWmqbla/rRhgQ6JlxBcyW9LqkRBo3zIlJKHqD38kYzw=;
 b=hl5w/YLPkXZo8JY8EZLEFhdVnzcaqx/lOR8/saJ62+AzNjLoCQ+S5Izr4P6zZGQakG
 O+9ABmcb1FNExrrb4nIdg+8gyQIpr3HCyzYrlUqvZwsVwUPwQStUQwOluvs6Ect4OQm6
 HFlAwaSjagrshuBpVu9CkARUAj8YlEm8s186HZiDtXtiVTVN0IZznXS/xtiVgJnj+6sC
 KFXQlHGTHicXb99hhbYOvhPjU1CUsu+T1Q3owv4xIPAR4eB9bBwBdwp0ndu2p+fAfFnR
 83JJhrO+TOrNEBoTOlIWTSOIckDLXAdaRa1pvH9TES46dLocgV0g0vHqSKAgldpf4aAQ
 g4yA==
X-Gm-Message-State: ALoCoQmmbU4yVx1QJPKvSgKoypafBPxgkw5RcTGD9B4GMFWIbidT93MQdf/jqF2W/kWtTAH6S4VZ
X-Received: by 10.68.57.197 with SMTP id k5mr35368386pbq.142.1445275163954;
 Mon, 19 Oct 2015 10:19:23 -0700 (PDT)
Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by smtp.gmail.com with ESMTPSA id dg2sm37350077pbb.9.2015.10.19.10.19.23
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 19 Oct 2015 10:19:23 -0700 (PDT)
Date: Mon, 19 Oct 2015 10:19:34 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Xie, Huawei" <huawei.xie@intel.com>
Message-ID: <20151019101934.6f3b92f9@xeon-e3>
In-Reply-To: <C37D651A908B024F974696C65296B57B4B12CC68@SHSMSX101.ccr.corp.intel.com>
References: <1445231772-17467-1-git-send-email-stephen@networkplumber.org>
 <1445231772-17467-5-git-send-email-stephen@networkplumber.org>
 <C37D651A908B024F974696C65296B57B4B12CC68@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>,
 "changchun.ouyang@intel.com" <changchun.ouyang@intel.com>
Subject: Re: [dpdk-dev] [PATCH 4/5] virtio: use any layout on transmit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 17:19:25 -0000

On Mon, 19 Oct 2015 16:28:30 +0000
"Xie, Huawei" <huawei.xie@intel.com> wrote:

> "When using legacy interfaces, transitional drivers which have not
> negotiated VIRTIO_F_ANY_LAYOUT
> MUST use a single descriptor for the struct virtio_net_hdr on both
> transmit and receive, with the
> network data in the following descriptors."
> 
> I think we shouldn't assume that virtio header descriptor uses a
> separate descriptor. It could be with data. Virtio RX(and dpdk vhost)
> actually is implemented like this before, i.e, i thought this should be
> inherent but not a feature.
> Is the current RX implementation wrong?

I believe current RX is ok, the any layout refers more to what is
handed to the host on transmit. Rusty said something like
"any sane implementation would work with contiguous buffer"
but the standard couldn't assume sanity!