From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 657FF593A for ; Sat, 24 Oct 2015 19:47:14 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 85CE98B137; Sat, 24 Oct 2015 17:47:13 +0000 (UTC) Received: from redhat.com (ovpn-116-113.ams2.redhat.com [10.36.116.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t9OHlBT8029236; Sat, 24 Oct 2015 13:47:11 -0400 Date: Sat, 24 Oct 2015 20:47:10 +0300 From: "Michael S. Tsirkin" To: Flavio Leitner Message-ID: <20151024204401-mutt-send-email-mst@redhat.com> References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <1445399294-18826-5-git-send-email-yuanhan.liu@linux.intel.com> <20151021133043-mutt-send-email-mst@redhat.com> <20151021124815.GG3115@yliu-dev.sh.intel.com> <20151021172336-mutt-send-email-mst@redhat.com> <20151022094955.GR3115@yliu-dev.sh.intel.com> <20151022142141-mutt-send-email-mst@redhat.com> <20151024023408.GA7182@x240.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151024023408.GA7182@x240.home> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org, marcel@redhat.com Subject: Re: [dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 17:47:14 -0000 On Sat, Oct 24, 2015 at 12:34:08AM -0200, Flavio Leitner wrote: > On Thu, Oct 22, 2015 at 02:32:31PM +0300, Michael S. Tsirkin wrote: > > On Thu, Oct 22, 2015 at 05:49:55PM +0800, Yuanhan Liu wrote: > > > On Wed, Oct 21, 2015 at 05:26:18PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, Oct 21, 2015 at 08:48:15PM +0800, Yuanhan Liu wrote: > > > > > > Please note that for virtio devices, guest is supposed to > > > > > > control the placement of incoming packets in RX queues. > > > > > > > > > > I may not follow you. > > > > > > > > > > Enqueuing packets to a RX queue is done at vhost lib, outside the > > > > > guest, how could the guest take the control here? > > > > > > > > > > --yliu > > > > > > > > vhost should do what guest told it to. > > > > > > > > See virtio spec: > > > > 5.1.6.5.5 Automatic receive steering in multiqueue mode > > > > > > Spec says: > > > > > > After the driver transmitted a packet of a flow on transmitqX, > > > the device SHOULD cause incoming packets for that flow to be > > > steered to receiveqX. > > > > > > > > > Michael, I still have no idea how vhost could know the flow even > > > after discussion with Huawei. Could you be more specific about > > > this? Say, how could guest know that? And how could guest tell > > > vhost which RX is gonna to use? > > > > > > Thanks. > > > > > > --yliu > > > > I don't really understand the question. > > > > When guests transmits a packet, it makes a decision > > about the flow to use, and maps that to a tx/rx pair of queues. > > > > It sends packets out on the tx queue and expects device to > > return packets from the same flow on the rx queue. > > Why? I can understand that there should be a mapping between > flows and queues in a way that there is no re-ordering, but > I can't see the relation of receiving a flow with a TX queue. > > fbl That's the way virtio chose to program the rx steering logic. It's low overhead (no special commands), and works well for TCP when user is an endpoint since rx and tx for tcp are generally tied (because of ack handling). We can discuss other ways, e.g. special commands for guests to program steering. We'd have to first see some data showing the current scheme is problematic somehow. > > During transmit, device needs to figure out the flow > > of packets as they are received from guest, and track > > which flows go on which tx queue. > > When it selects the rx queue, it has to use the same table. > > > > There is currently no provision for controlling > > steering for uni-directional > > flows which are possible e.g. with UDP. > > > > We might solve this in a future spec - for example, set a flag notifying > > guest that steering information is missing for a given flow, for example > > by setting a flag in a packet, or using the command queue, and have > > guest send a dummy empty packet to set steering rule for this flow. > > > > > > -- > > MST > >