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?
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
