qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] virtio-net: support RSC v4/v6 tcp traffic for W


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] virtio-net: support RSC v4/v6 tcp traffic for Windows HCK
Date: Tue, 13 Nov 2018 10:32:59 -0500

On Tue, Nov 13, 2018 at 10:21:07AM +0200, Yuri Benditovich wrote:
> 
> 
> On Mon, Nov 12, 2018 at 10:53 PM Michael S. Tsirkin <address@hidden> wrote:
> 
>     On Mon, Nov 12, 2018 at 01:31:36PM +0200, Yuri Benditovich wrote:
>     >
>     >
>     > On Mon, Nov 12, 2018 at 11:26 AM Jason Wang <address@hidden> wrote:
>     >
>     >
>     >     On 2018/11/12 下午4:57, Yuri Benditovich wrote:
>     >     >
>     >     > On Mon, Nov 12, 2018 at 4:54 AM Michael S. Tsirkin <address@hidden
>     >     > <mailto:address@hidden>> wrote:
>     >     >
>     >     >     On Sun, Nov 11, 2018 at 12:18:54PM +0200, Yuri Benditovich
>     wrote:
>     >     >     >     > @@ -66,12 +143,16 @@ typedef struct VirtIONet {
>     >     >     >     >      VirtIONetQueue *vqs;
>     >     >     >     >      VirtQueue *ctrl_vq;
>     >     >     >     >      NICState *nic;
>     >     >     >     > +    QTAILQ_HEAD(, NetRscChain) rsc_chains;
>     >     >     >
>     >     >     >     what exactly happens with these chains on migration?
>     >     >     >
>     >     >     >
>     >     >     > This feature (software implementation of RSC in QEMU) is
>     >     >     intended to be used in
>     >     >     > the environment of certification tests which never uses
>     migration.
>     >     >
>     >     >     Should this feature disable migration then?
>     >     >
>     >     >
>     >     > IMO, this should not. But if you find it mandatory, please respond
>     and
>     >     > I will add the migration blocker.
>     >
>     >
>     >     So if my understanding is correct, it's safe to do nothing even if 
> we
>     >     allow migration for RSC?
>     >
>     >
>     > This does not create any unrecoverable failure (assertion, BSOD),
>     although
>     > some data (coalesced parts of packets not delivered yet to guest) will 
> be
>     lost.
> 
>     If guest has no way to detect none of these packets were ever
>     received by card, then I guess it's fine. Needs a
>     comment in case we start caring about packet loss around
>     migration.
> 
> 
> 
> Where is the best place to place such a comment in the code?

Maybe where we add the fields that we don't bother migrating.


> Are there more notes toward v3 of the patch?
> 

Not yet.

> 
>     >
>     >
>     >     Thanks
>     >
>     >
>     >
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]