search for: destructor_arg

...i; > > copylen = vnet_hdr.hdr_len ? > @@ -724,11 +724,11 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m, > tap = rcu_dereference(q->tap); > /* copy skb_ubuf_info for callback when skb has no error */ > if (zerocopy) { > - skb_shinfo(skb)->destructor_arg = m->msg_control; > + skb_shinfo(skb)->destructor_arg = msg_control; > skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY; > skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG; > - } else if (m && m->msg_control) { > - struct ubuf_info *uarg = m->msg_contro...

...CK_ZEROCOPY)) { struct iov_iter i; copylen = vnet_hdr.hdr_len ? @@ -724,11 +724,11 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m, tap = rcu_dereference(q->tap); /* copy skb_ubuf_info for callback when skb has no error */ if (zerocopy) { - skb_shinfo(skb)->destructor_arg = m->msg_control; + skb_shinfo(skb)->destructor_arg = msg_control; skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY; skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG; - } else if (m && m->msg_control) { - struct ubuf_info *uarg = m->msg_control; + } else if (msg_contr...

...gt; 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 100644 >> --...

...gt; 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 100644 >> --...

...t; 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 sk...

...t; 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 sk...

...ocked 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. >>> > > >>&...

...ocked 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. >>> > > >>&...

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

...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 and netback exchange...

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

tun supports zero copy transmit since 0690899b4d4501b3505be069b9a687e68ccbe15b, however you can only enable this mode if you know your workload does not trigger heavy guest to host/host to guest traffic - otherwise you get a (minor) performance regression. This patchset addresses this problem by notifying the owner device when callback is invoked because of a data copy. This makes it possible to

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP

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

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP