diff mbox series

[2/4] bus/vmbus: add host latency tuning function

Message ID 20180809175008.5787-3-stephen@networkplumber.org (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series netvsc performance enhancements |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Stephen Hemminger Aug. 9, 2018, 5:50 p.m. UTC 
  Add vmbus API to allow tuning the scan interval on the host side.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
 drivers/bus/vmbus/rte_bus_vmbus.h           | 15 ++++++++++++
 drivers/bus/vmbus/rte_bus_vmbus_version.map |  1 +
 drivers/bus/vmbus/vmbus_channel.c           | 26 +++++++++++++++++++++
 3 files changed, 42 insertions(+)

Comments

Ferruh Yigit Aug. 23, 2018, 2:45 p.m. UTC | #1 
On 8/9/2018 6:50 PM, Stephen Hemminger wrote:
> Add vmbus API to allow tuning the scan interval on the host side.
> 
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>

<...>

> @@ -20,6 +20,7 @@ DPDK_18.08 {
>  	rte_vmbus_probe;
>  	rte_vmbus_register;
>  	rte_vmbus_scan;
> +	rte_vmbus_set_latency;
>  	rte_vmbus_sub_channel_index;
>  	rte_vmbus_subchan_open;
>  	rte_vmbus_unmap_device;

Needs to be on DPDK_18.11 now, will fix while merging.

(Since this is not really a public API, I think no need to mark as experimental
as process and checkpatches requires.)
Stephen Hemminger Aug. 23, 2018, 3:40 p.m. UTC | #2 
On Thu, 23 Aug 2018 15:45:44 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 8/9/2018 6:50 PM, Stephen Hemminger wrote:
> > Add vmbus API to allow tuning the scan interval on the host side.
> > 
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>  
> 
> <...>
> 
> > @@ -20,6 +20,7 @@ DPDK_18.08 {
> >  	rte_vmbus_probe;
> >  	rte_vmbus_register;
> >  	rte_vmbus_scan;
> > +	rte_vmbus_set_latency;
> >  	rte_vmbus_sub_channel_index;
> >  	rte_vmbus_subchan_open;
> >  	rte_vmbus_unmap_device;  
> 
> Needs to be on DPDK_18.11 now, will fix while merging.
> 
> (Since this is not really a public API, I think no need to mark as experimental
> as process and checkpatches requires.)

Sure, thanks. I was testing on 18.08.  We need to be able to figure
out internal versus public API symbols at some point.  It doesn't matter
if a bus API changes if there is no userspace API that can directly access it.
diff mbox series

Patch

diff --git a/drivers/bus/vmbus/rte_bus_vmbus.h b/drivers/bus/vmbus/rte_bus_vmbus.h
index 4a2c1f6fd918..2839fef5b27a 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus.h
+++ b/drivers/bus/vmbus/rte_bus_vmbus.h
@@ -364,6 +364,21 @@  void rte_vmbus_chan_signal_read(struct vmbus_channel *chan, uint32_t bytes_read)
  */
 uint16_t rte_vmbus_sub_channel_index(const struct vmbus_channel *chan);
 
+/**
+ * Set the host monitor latency hint
+ *
+ * @param dev
+ *    VMBUS device
+ * @param chan
+ *	Pointer to vmbus_channel structure.
+ * @param latency
+ *	Approximate wait period between hypervisor examinations of
+ *	the trigger page (in nanoseconds).
+ */
+void rte_vmbus_set_latency(const struct rte_vmbus_device *dev,
+			   const struct vmbus_channel *chan,
+			   uint32_t latency);
+
 /**
  * Register a VMBUS driver.
  *
diff --git a/drivers/bus/vmbus/rte_bus_vmbus_version.map b/drivers/bus/vmbus/rte_bus_vmbus_version.map
index dabb9203104b..5b01ff30d7b0 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus_version.map
+++ b/drivers/bus/vmbus/rte_bus_vmbus_version.map
@@ -20,6 +20,7 @@  DPDK_18.08 {
 	rte_vmbus_probe;
 	rte_vmbus_register;
 	rte_vmbus_scan;
+	rte_vmbus_set_latency;
 	rte_vmbus_sub_channel_index;
 	rte_vmbus_subchan_open;
 	rte_vmbus_unmap_device;
diff --git a/drivers/bus/vmbus/vmbus_channel.c b/drivers/bus/vmbus/vmbus_channel.c
index cc5f3e8379a5..bd14c0662b46 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -59,6 +59,32 @@  vmbus_set_event(const struct rte_vmbus_device *dev,
 	vmbus_set_monitor(dev, chan->monitor_id);
 }
 
+/*
+ * Set the wait between when hypervisor examines the trigger.
+ */
+void
+rte_vmbus_set_latency(const struct rte_vmbus_device *dev,
+		      const struct vmbus_channel *chan,
+		      uint32_t latency)
+{
+	uint32_t trig_idx = chan->monitor_id / VMBUS_MONTRIG_LEN;
+	uint32_t trig_offs = chan->monitor_id % VMBUS_MONTRIG_LEN;
+
+	if (latency >= UINT16_MAX * 100) {
+		VMBUS_LOG(ERR, "invalid latency value %u", latency);
+		return;
+	}
+
+	if (trig_idx >= VMBUS_MONTRIGS_MAX) {
+		VMBUS_LOG(ERR, "invalid monitor trigger %u",
+			  trig_idx);
+		return;
+	}
+
+	/* Host value is expressed in 100 nanosecond units */
+	dev->monitor_page->lat[trig_idx][trig_offs] = latency / 100;
+}
+
 /*
  * Notify host that there are data pending on our TX bufring.
  *