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 5F734C32C for ; Thu, 22 Oct 2015 16:19:05 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 9CD10A8A; Thu, 22 Oct 2015 14:19:04 +0000 (UTC) Received: from redhat.com (ovpn-116-113.ams2.redhat.com [10.36.116.113]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t9MEJ2ga012446; Thu, 22 Oct 2015 10:19:02 -0400 Date: Thu, 22 Oct 2015 17:19:01 +0300 From: "Michael S. Tsirkin" To: Yuanhan Liu Message-ID: <20151022171750-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> <20151022140710.GU3115@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151022140710.GU3115@yliu-dev.sh.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 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: Thu, 22 Oct 2015 14:19:05 -0000 On Thu, Oct 22, 2015 at 10:07:10PM +0800, Yuanhan Liu 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. > > > > 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. > > Thanks for the length explanation, Michael! > > I guess the key is are we able to get the table inside vhost-user > lib? And, are you looking for something like following? > > static int rte_vhost_enqueue_burst(pkts) > { > for_each_pkts(pkt) { > int rxq = get_rxq_from_table(pkt); > > queue_to_rxq(pkt, rxq); > } > } > > BTW, there should be such implementation at some where, right? > If so, would you please point it to me? See tun_flow_update in drivers/net/tun.c in Linux. > In the meanwhile, I will read more doc/code to try to understand > it. > > --yliu > > > > > 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