hyperv: Enable batched notification
Subsystems (3)
v2 cover hyperv: Enable batched notification
Take into consideration the xmit_more flag in skb to decide if we should notify the host as we place packets in VMBUS.
The VMBUS API that would give us this control is already in Greg's tree, in this patch-set, that API is exported so it can be used in the netvsc driver.
Also included here is a siganlling related fix in the vmbus driver that is exposed by the netvsc driver. I would like to thank
Jason Wang <[email protected]> for pointing out this issue.
This version of the patch-set, adds an additional patch to fix the signalling issue.
K. Y. Srinivasan (3):
Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
hyperv: Support batched notification
drivers/hv/channel.c | 33 +++++++++++++++++++++++++++++++++ drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc.c | 14 +++++++++----- drivers/net/hyperv/netvsc_drv.c | 3 ++- drivers/net/hyperv/rndis_filter.c | 2 +- 5 files changed, 46 insertions(+), 8 deletions(-)
Signature · 1 line
1.7.4.1
PATCH v2 1/3 Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
Export the vmbus_sendpacket_pagebuffer_ctl() interface. This interface will be used in the netvsc driver to optimize signalling the host.
--- drivers/hv/channel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/hv/channel.c +1 -0
@@ -710,6 +710,7 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel,return ret; } +EXPORT_SYMBOL_GPL (vmbus_sendpacket_pagebuffer_ctl);/* * vmbus_sendpacket_pagebuffer - Send a range of single-page buffer
Signature · 1 line
1.7.4.1
PATCH v2 2/3 Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
When the caller specifies that signalling should be deferred, we need to address the case where we are not able to place the current packet because the buffer is full. In this case, we will signal the host as some packets may have been placed on the ring buffer.
I would like to thank Jason Wang <[email protected]> for pointing out this issue.
--- drivers/hv/channel.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)
drivers/hv/channel.c +32 -0
@@ -614,8 +614,24 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);return ret; }
@@ -705,8 +721,24 @@ int vmbus_sendpacket_pagebuffer_ctl(struct vmbus_channel *channel, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);return ret; }
Signature · 1 line
1.7.4.1
Re: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
Quoted 68 lines · K. Y. Srinivasan
When the caller specifies that signalling should be deferred, we need to address the case where we are not able to place the current packet because the buffer is full. In this case, we will signal the host as some packets may have been placed on the ring buffer.
I would like to thank Jason Wang <[email protected]> for pointing out this issue.Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/hv/channel.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)drivers/hv/channel.c +16
-0@@ -614,8 +614,24 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);drivers/hv/channel.c +16
-0return ret; }@@ -705,8 +721,24 @@ int vmbus_sendpacket_pagebuffer_ctl(structvmbus_channel *channel, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);
Quoted 3 lines
return ret;
}
Looks like we need to kick unconditionally here. Consider we may get -EAGAIN when we want to send the last skb (kick_q is true) from the list. We need kick host in this case.
Btw, another method is let the driver to decide e.g exporting the vmbus_setevent() and call it in netvsc_start_xmit().
RE: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
Quoted 92 lines
-----Original Message-----
From: Jason Wang [mailto:[email protected]]
Sent: Wednesday, March 11, 2015 8:08 PM
To: KY Srinivasan
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; KY Srinivasan
Subject: Re: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic withkick_qQuoted 68 lines · K. Y. Srinivasan
When the caller specifies that signalling should be deferred, we need to address the case where we are not able to place the current packet because the buffer is full. In this case, we will signal the host as some packets may have been placed on the ring buffer.
I would like to thank Jason Wang <[email protected]> for pointing out this issue.Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/hv/channel.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)drivers/hv/channel.c index renamed from drivers/hv/channel.c +0
-0e58cdb7..ae06ba9 100644
drivers/hv/channel.c +16
-0@@ -614,8 +614,24 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);drivers/hv/channel.c +16
-0return ret; }@@ -705,8 +721,24 @@ int vmbus_sendpacket_pagebuffer_ctl(structvmbus_channel *channel, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);Quoted 3 lines
return ret;
}
--Looks like we need to kick unconditionally here. Consider we may get - EAGAIN when we want to send the last skb (
kick_qis true) from the list. We need kick host in this case.
Quoted 2 lines
Btw, another method is let the driver to decide e.g exporting the
vmbus_setevent()and call it innetvsc_start_xmit().
There is other state that governs if the host needs to be signaled and I don't think we want to expose that to netvsc. In any case, netvsc will have to signal the host when EGAIN is received. We might as well do it in the vmbus driver.
Thank you Jason, I will respin and resubmit the series.
K. Y
Quoted 3 lines
RE: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic with kick_q
Quoted 109 lines
-----Original Message-----
From: devel [mailto:[email protected]] On Behalf Of KY Srinivasan
Sent: Wednesday, March 11, 2015 8:32 PM
To: Jason Wang
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: RE: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic withkick_qQuoted 26 lines
-----Original Message-----
From: Jason Wang [mailto:[email protected]]
Sent: Wednesday, March 11, 2015 8:08 PM
To: KY Srinivasan
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; KY Srinivasan
Subject: Re: [PATCH V2 2/3 net-next] Drivers: hv: vmbus: Fix a bug in the signalling logic withkick_qQuoted 12 lines · K. Y. Srinivasan
When the caller specifies that signalling should be deferred, we need to address the case where we are not able to place the current packet because the buffer is full. In this case, we will signal the host as some packets may have been placed on the ring buffer. I would like to thank Jason Wang <[email protected]> for pointing out this issue.
Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/hv/channel.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)Quoted 5 lines
drivers/hv/channel.c int vmbus_sendpacket_ctl(struct
Quoted 5 lines
drivers/hv/channel.c index renamed from drivers/hv/channel.c +0
-0e58cdb7..ae06ba9 100644
drivers/hv/channel.c +0
-0@@ -614,8 +614,24 @@ int vmbus_sendpacket_ctl(struct
vmbus_channelQuoted 59 lines
Quoted 51 lines
drivers/hv/channel.c +16
-0*channel, void *buffer, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);drivers/hv/channel.c +16
-0return ret; }@@ -705,8 +721,24 @@ int vmbus_sendpacket_pagebuffer_ctl(structvmbus_channel *channel, ret =hv_ringbuffer_write (&channel->outbound, bufferlist,3 , &signal); +/* +* Here is the logic for signalling the host: +* 1. If the host is already draining the ringbuffer, +* don't signal. This is indicated by the parameter +* "signal". +* +* 2. If we are not able to write, signal if kick_q is false. +* kick_q being false indicates that we may have placed zero or +* more packets with more packets to come. We will signal in +* this case even if potentially we may have not placed any +* packet. This is a rare enough condition that it should not +* matter. +*/ +if ((ret ==0 ) && kick_q && signal)vmbus_setevent (channel); +else if ((ret !=0 ) && !kick_q) +vmbus_setevent (channel);Quoted 3 lines
return ret;
}
--Looks like we need to kick unconditionally here. Consider we may get - EAGAIN when we want to send the last skb (
kick_qis true) from the list. We need kick host in this case.Quoted 2 lines
Btw, another method is let the driver to decide e.g exporting the
vmbus_setevent()and call it innetvsc_start_xmit().
Quoted 6 lines
There is other state that governs if the host needs to be signaled and I don't think we want to expose that to netvsc. In any case, netvsc will have to signal the host when EGAIN is received.
We might as well do it in the vmbus driver.Thank you Jason, I will respin and resubmit the series.
Looks like there may be a way to make the signaling more precise even in this case. I am going to experiment with it.
K. Y
Quoted 10 lines
K. Y
Quoted 3 lines
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
PATCH v2 3/3 hyperv: Support batched notification
In reply to K. Y. SrinivasanOptimize notifying the host by deferring notification until there are no more packets to be sent. This will help in batching the requests on the host.
--- drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc.c | 14 +++++++++----- drivers/net/hyperv/netvsc_drv.c | 3 ++- drivers/net/hyperv/rndis_filter.c | 2 +- 4 files changed, 13 insertions(+), 8 deletions(-)
drivers/net/hyperv/hyperv_net.h +1 -1
@@ -184,7 +184,7 @@ struct rndis_device {int netvsc_device_add (struct hv_device *device,void *additional_info);int netvsc_device_remove (struct hv_device *device);int netvsc_send (struct hv_device *device, -struct hv_netvsc_packet *packet); +struct hv_netvsc_packet *packet,bool kick_q);void netvsc_linkstatus_callback (struct hv_device *device_obj,struct rndis_message *resp); int netvsc_recv_callback(struct hv_device *device_obj,
drivers/net/hyperv/netvsc.c +9 -5
@@ -707,7 +707,7 @@ static u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device, }int netvsc_send (struct hv_device *device, -struct hv_netvsc_packet *packet) +struct hv_netvsc_packet *packet,bool kick_q) {struct netvsc_device *net_device;int ret =0 ;
@@ -719,6 +719,7 @@ int netvsc_send(struct hv_device *device,u32 msg_size =0 ;struct sk_buff *skb =NULL ;u16 q_idx = packet->q_idx; +u32 vmbus_flags =VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED ; net_device =get_outbound_net_device (device);
@@ -768,18 +769,21 @@ int netvsc_send(struct hv_device *device,return -ENODEV ;if (packet->page_buf_cnt) { - ret =vmbus_sendpacket_pagebuffer (out_channel, + ret =vmbus_sendpacket_pagebuffer_ctl (out_channel, packet->page_buf, packet->page_buf_cnt, &sendMessage,sizeof (struct nvsp_message ), - req_id); + req_id, + vmbus_flags, + kick_q); }else { - ret =vmbus_sendpacket (out_channel, &sendMessage, + ret =vmbus_sendpacket_ctl (out_channel, &sendMessage,sizeof (struct nvsp_message ), req_id,VM_PKT_DATA_INBAND , -VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED ); + vmbus_flags, + kick_q); }if (ret ==0 ) {
drivers/net/hyperv/netvsc_drv.c +2 -1
@@ -384,6 +384,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)u32 net_trans_info;u32 hash;u32 skb_length = skb->len; +bool kick_q = !skb->xmit_more;/* We will atmost need two pages to describe the rndis
@@ -556,7 +557,7 @@ do_send: packet->page_buf_cnt =init_page_array (rndis_msg, rndis_msg_size, skb, &packet->page_buf[0 ]); - ret =netvsc_send (net_device_ctx->device_ctx, packet); + ret =netvsc_send (net_device_ctx->device_ctx, packet, kick_q); drop:if (ret ==0 ) {
drivers/net/hyperv/rndis_filter.c +1 -1
@@ -238,7 +238,7 @@ static int rndis_filter_send_request(struct rndis_device *dev, packet->send_completion =NULL ; - ret =netvsc_send (dev->net_dev->dev, packet); + ret =netvsc_send (dev->net_dev->dev, packet, true);return ret; }
Signature · 1 line
1.7.4.1
Re: [PATCH V2 3/3 net-next] hyperv: Support batched notification
Quoted 88 lines · K. Y. Srinivasan
Optimize notifying the host by deferring notification until there are no more packets to be sent. This will help in batching the requests on the host.
Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc.c | 14 +++++++++----- drivers/net/hyperv/netvsc_drv.c | 3 ++- drivers/net/hyperv/rndis_filter.c | 2 +- 4 files changed, 13 insertions(+), 8 deletions(-)drivers/net/hyperv/hyperv_net.h +1
-1@@ -184,7 +184,7 @@ struct rndis_device {int netvsc_device_add (struct hv_device *device,void *additional_info);int netvsc_device_remove (struct hv_device *device);int netvsc_send (struct hv_device *device, -struct hv_netvsc_packet *packet); +struct hv_netvsc_packet *packet,bool kick_q);void netvsc_linkstatus_callback (struct hv_device *device_obj,struct rndis_message *resp);int netvsc_recv_callback(struct
hv_device*device_obj,drivers/net/hyperv/netvsc.c +1
-1@@ -707,7 +707,7 @@ static u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device, }int netvsc_send (struct hv_device *device, -struct hv_netvsc_packet *packet) +struct hv_netvsc_packet *packet,bool kick_q) {struct netvsc_device *net_device;drivers/net/hyperv/netvsc.c +8
-4int ret =0 ;@@ -719,6 +719,7 @@ int netvsc_send(struct hv_device *device,u32 msg_size =0 ;struct sk_buff *skb =NULL ;u16 q_idx = packet->q_idx; +u32 vmbus_flags =VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED ; net_device =get_outbound_net_device (device);@@ -768,18 +769,21 @@ int netvsc_send(struct hv_device *device,return -ENODEV ;if (packet->page_buf_cnt) { - ret =vmbus_sendpacket_pagebuffer (out_channel, + ret =vmbus_sendpacket_pagebuffer_ctl (out_channel, packet->page_buf, packet->page_buf_cnt, &sendMessage,sizeof (struct nvsp_message ), - req_id); + req_id, + vmbus_flags, + kick_q); }else { - ret =vmbus_sendpacket (out_channel, &sendMessage, + ret =vmbus_sendpacket_ctl (out_channel, &sendMessage,sizeof (struct nvsp_message ), req_id,VM_PKT_DATA_INBAND , -VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED ); + vmbus_flags, + kick_q); }if (ret ==0 ) {drivers/net/hyperv/netvsc_drv.c +1
-0@@ -384,6 +384,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) u32 net_trans_info;u32 hash;u32 skb_length = skb->len; +bool kick_q = !skb->xmit_more;drivers/net/hyperv/netvsc_drv.c +0
-0/* We will atmost need two pages to describe the rndis
drivers/net/hyperv/netvsc_drv.c do_send: · line 560
Quoted 5 lines
drivers/net/hyperv/netvsc_drv.c +1
-1@@ -556,7 +557,7 @@ do_send: packet->page_buf_cnt =init_page_array (rndis_msg, rndis_msg_size, skb, &packet->page_buf[0 ]); - ret =netvsc_send (net_device_ctx->device_ctx, packet); + ret =netvsc_send (net_device_ctx->device_ctx, packet, kick_q);
Maybe just a !skb->xmit_more here to save a local variable.
Quoted 25 lines
drivers/net/hyperv/netvsc_drv.c +0
-0drop:if (ret ==0 ) {drivers/net/hyperv/rndis_filter.c +1
-1@@ -238,7 +238,7 @@ static int rndis_filter_send_request(struct rndis_device *dev, packet->send_completion =NULL ; - ret =netvsc_send (dev->net_dev->dev, packet); + ret =netvsc_send (dev->net_dev->dev, packet, true);return ret; }Signature · 7 lines
-- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 3/3 net-next] hyperv: Support batched notification
Quoted 107 lines
-----Original Message-----
From: Jason Wang [mailto:[email protected]]
Sent: Wednesday, March 11, 2015 8:09 PM
To: KY Srinivasan
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; KY Srinivasan
Subject: Re: [PATCH V2 3/3 net-next] hyperv: Support batched notificationQuoted 39 lines · K. Y. Srinivasan
Optimize notifying the host by deferring notification until there are no more packets to be sent. This will help in batching the requests on the host.
Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc.c | 14 +++++++++----- drivers/net/hyperv/netvsc_drv.c | 3 ++- drivers/net/hyperv/rndis_filter.c | 2 +- 4 files changed, 13 insertions(+), 8 deletions(-)(quoted diff) +0
-0
b/drivers/net/hyperv/hyperv_net.hindex 4815843..3fd9896 100644drivers/net/hyperv/hyperv_net.h +0
-0@@ -184,7 +184,7 @@ struct rndis_device { int netvsc_device_add(struct hv_device *device, void *additional_info);int
netvsc_device_remove(struct hv_device *device); int netvsc_send(structhv_device*device,drivers/net/hyperv/hyperv_net.h +1
-1- struct hv_netvsc_packet *packet); + struct hv_netvsc_packet *packet, bool kick_q);void netvsc_linkstatus_callback (struct hv_device *device_obj,struct rndis_message *resp); int netvsc_recv_callback(struct hv_device *device_obj, diff --git
a/drivers/net/hyperv/netvsc.cb/drivers/net/hyperv/netvsc.cindex 208eb05..9003b94 100644drivers/net/hyperv/netvsc.c +1
-1@@ -707,7 +707,7 @@ static u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device, }int netvsc_send (struct hv_device *device, -struct hv_netvsc_packet *packet) +struct hv_netvsc_packet *packet,bool kick_q) {struct netvsc_device *net_device;int ret =0 ;drivers/net/hyperv/netvsc.c int netvsc_send(struct hv_device *device, · line 722
Quoted 4 lines
drivers/net/hyperv/netvsc.c +1
-0@@ -719,6 +719,7 @@ int netvsc_send(struct hv_device *device,u32 msg_size =0 ;struct sk_buff *skb =NULL ;u16 q_idx = packet->q_idx; + u32 vmbus_flags =
VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED;drivers/net/hyperv/netvsc.c int netvsc_send(struct hv_device *device, · line 723
Quoted 3 lines
drivers/net/hyperv/netvsc.c +0
-0net_device = get_outbound_net_device(device); @@ -768,18+769,21 @@
drivers/net/hyperv/netvsc.c int netvsc_send(struct hv_device *device,
Quoted 10 lines
drivers/net/hyperv/netvsc.c +0
-0int netvsc_send(struct hv_device *device, return -ENODEV;drivers/net/hyperv/netvsc.c +1
-1if (packet->page_buf_cnt) { - ret = vmbus_sendpacket_pagebuffer(out_channel, + ret = vmbus_sendpacket_pagebuffer_ctl(out_channel, packet->page_buf, packet->page_buf_cnt, &sendMessage, sizeof(struct
nvsp_message),drivers/net/hyperv/netvsc.c int netvsc_send(struct hv_device *device,
Quoted 11 lines
drivers/net/hyperv/netvsc.c +4
-3- req_id); + req_id, + vmbus_flags, + kick_q); }else { - ret = vmbus_sendpacket(out_channel, &sendMessage, + ret = vmbus_sendpacket_ctl(out_channel, &sendMessage, sizeof(struct nvsp_message), req_id, VM_PKT_DATA_INBAND, -VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);Quoted 17 lines
drivers/net/hyperv/netvsc.c +2
-0+ vmbus_flags, + kick_q); }if (ret ==0 ) {(quoted diff) +0
-0
b/drivers/net/hyperv/netvsc_drv.cindex a06bd66..80b4b29 100644drivers/net/hyperv/netvsc_drv.c +1
-0@@ -384,6 +384,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) u32 net_trans_info;u32 hash;u32 skb_length = skb->len; +bool kick_q = !skb->xmit_more;drivers/net/hyperv/netvsc_drv.c
Quoted 3 lines
drivers/net/hyperv/netvsc_drv.c +1
-0/* We will atmost need two pages to describe the rndis @@ -556,7 +557,7 @@ do_send: packet->page_buf_cnt = init_page_array(rndis_msg,
rndis_msg_size,
Quoted 6 lines
drivers/net/hyperv/netvsc_drv.c do_send: · line 560
Quoted 4 lines
drivers/net/hyperv/netvsc_drv.c +1
-1skb, &packet->page_buf[0]); - ret =netvsc_send (net_device_ctx->device_ctx, packet); + ret =netvsc_send (net_device_ctx->device_ctx, packet, kick_q);Maybe just a !skb->xmit_more here to save a local variable.
Will fix it.
K. Y
Re: [PATCH V2 1/3 net-next] Drivers: hv: vmbus: Export the vmbus_sendpacket_pagebuffer_ctl()
In reply to K. Y. SrinivasanQuoted 20 lines · K. Y. Srinivasan
Export the
vmbus_sendpacket_pagebuffer_ctl()interface. This interface will be used in the netvsc driver to optimize signalling the host.Signed-off-by K. Y. Srinivasan <[email protected]>--- drivers/hv/channel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)drivers/hv/channel.c +1
-0@@ -710,6 +710,7 @@ int vmbus_sendpacket_pagebuffer_ctl(structvmbus_channel *channel, return ret; } +EXPORT_SYMBOL_GPL (vmbus_sendpacket_pagebuffer_ctl);/*
Quoted 3 lines
*
vmbus_sendpacket_pagebuffer- Send a range of single-page bufferSignature · 1 line
1.7.4.1