search for: rcuify

...;> >>> Thoughts? >>> >> >> Agree, vhost net removal should not be blocked by a skb. But since the >> skbs could be queued may places, just destroy them may need extra locks. >> >> Haven't thought this deeply, but another possible sloution is to rcuify >> destructor_arg and assign it to NULL during vhost_net removing. > > Xen treat it by a timer, for those skbs which has been delivered for a > while, netback would exchange page of zero_copy's skb with dom0's page. > > but there is still a race between host's anoth...

...;> >>> Thoughts? >>> >> >> Agree, vhost net removal should not be blocked by a skb. But since the >> skbs could be queued may places, just destroy them may need extra locks. >> >> Haven't thought this deeply, but another possible sloution is to rcuify >> destructor_arg and assign it to NULL during vhost_net removing. > > Xen treat it by a timer, for those skbs which has been delivered for a > while, netback would exchange page of zero_copy's skb with dom0's page. > > but there is still a race between host's anoth...

...stead? > I think this happens when a device is removed. > > Thoughts? > Agree, vhost net removal should not be blocked by a skb. But since the skbs could be queued may places, just destroy them may need extra locks. Haven't thought this deeply, but another possible sloution is to rcuify destructor_arg and assign it to NULL during vhost_net removing. >> --- >> drivers/vhost/net.c | 17 +++++++---------- >> 1 file changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c >> index a0fa5de..3e96e47 10...

...stead? > I think this happens when a device is removed. > > Thoughts? > Agree, vhost net removal should not be blocked by a skb. But since the skbs could be queued may places, just destroy them may need extra locks. Haven't thought this deeply, but another possible sloution is to rcuify destructor_arg and assign it to NULL during vhost_net removing. >> --- >> drivers/vhost/net.c | 17 +++++++---------- >> 1 file changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c >> index a0fa5de..3e96e47 10...

...e, vhost net removal should not be blocked by a skb. But since the >>>> > >>skbs could be queued may places, just destroy them may need extra locks. >>>> > >> >>>> > >>Haven't thought this deeply, but another possible sloution is to rcuify >>>> > >>destructor_arg and assign it to NULL during vhost_net removing. >>> > > >>> > >Xen treat it by a timer, for those skbs which has been delivered for a >>> > >while, netback would exchange page of zero_copy's skb with dom0...

...e, vhost net removal should not be blocked by a skb. But since the >>>> > >>skbs could be queued may places, just destroy them may need extra locks. >>>> > >> >>>> > >>Haven't thought this deeply, but another possible sloution is to rcuify >>>> > >>destructor_arg and assign it to NULL during vhost_net removing. >>> > > >>> > >Xen treat it by a timer, for those skbs which has been delivered for a >>> > >while, netback would exchange page of zero_copy's skb with dom0...

...? > >>> > >> > >>Agree, vhost net removal should not be blocked by a skb. But since the > >>skbs could be queued may places, just destroy them may need extra locks. > >> > >>Haven't thought this deeply, but another possible sloution is to rcuify > >>destructor_arg and assign it to NULL during vhost_net removing. > > > >Xen treat it by a timer, for those skbs which has been delivered for a > >while, netback would exchange page of zero_copy's skb with dom0's page. > > > >but there is still a rac...

...hen a device is removed. >> >> Thoughts? >> > > Agree, vhost net removal should not be blocked by a skb. But since the > skbs could be queued may places, just destroy them may need extra locks. > > Haven't thought this deeply, but another possible sloution is to rcuify > destructor_arg and assign it to NULL during vhost_net removing. Xen treat it by a timer, for those skbs which has been delivered for a while, netback would exchange page of zero_copy's skb with dom0's page. but there is still a race between host's another process handle the skb a...

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+