[PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

[K. Y. Srinivasan]

The macro startget_to_rport() can return NULL; handle that case
properly.

Signed-off-by: K. Y. Srinivasan 
Cc: 
---
 drivers/scsi/scsi_transport_fc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 24eaaf6..42a908f 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -2081,7 +2081,7 @@ fc_timed_out(struct scsi_cmnd *scmd)
 {
struct fc_rport *rport = starget_to_rport(scsi_target(scmd->device));
 
-   if (rport->port_state == FC_PORTSTATE_BLOCKED)
+   if ((rport == NULL) || (rport->port_state == FC_PORTSTATE_BLOCKED))
return BLK_EH_RESET_TIMER;
 
return BLK_EH_NOT_HANDLED;
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

[James Bottomley]

On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> The macro startget_to_rport() can return NULL; handle that case
> properly.

OK, can we unwind why you think you could possibly need this?  It would
mean that fc_timed_out was called for a non-FC device, which was
thought to be an impossibility when the fc transport class was
designed.

James

> Signed-off-by: K. Y. Srinivasan 
> Cc: 
> ---
>  drivers/scsi/scsi_transport_fc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_transport_fc.c
> b/drivers/scsi/scsi_transport_fc.c
> index 24eaaf6..42a908f 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -2081,7 +2081,7 @@ fc_timed_out(struct scsi_cmnd *scmd)
>  {
>   struct fc_rport *rport = starget_to_rport(scsi_target(scmd
> ->device));
>  
> - if (rport->port_state == FC_PORTSTATE_BLOCKED)
> + if ((rport == NULL) || (rport->port_state ==
> FC_PORTSTATE_BLOCKED))
>   return BLK_EH_RESET_TIMER;
>  
>   return BLK_EH_NOT_HANDLED;

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

[John Fastabend]

On 16-01-07 05:28 AM, Vitaly Kuznetsov wrote:
> Eric Dumazet  writes:
> 
>> On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
>>> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
>>>  VLAN ID to flow_keys")) introduced a performance regression in netvsc
>>> driver. Is problem is, however, not the above mentioned commit but the
>>> fact that netvsc_set_hash() function did some assumptions on the struct
>>> flow_keys data layout and this is wrong. We need to extract the data we
>>> need (src/dst addresses and ports) after the dissect.
>>>
>>> The issue could also be solved in a completely different way: as suggested
>>> by Eric instead of our own homegrown netvsc_set_hash() we could use
>>> skb_get_hash() which does more or less the same. Unfortunately, the
>>> testing done by Simon showed that Hyper-V hosts are not happy with our
>>> Jenkins hash, selecting the output queue with the current algorithm based
>>> on Toeplitz hash works significantly better.
>>

Also can I ask the maybe naive question. It looks like the hypervisor
is populating some table via a mailbox msg and this is used to select
the queues I guess with some sort of weighting function?

What happens if you just remove select_queue altogether? Or maybe just
what is this 16 entry table doing? How does this work on my larger
systems with 64+ cores can I only use 16 cores? Sorry I really have
no experience with hyperV and this got me curious.

Thanks,
John

>> Were tests done on IPv6 traffic ?
>>
> 
> Simon, could you please test this patch for IPv6 and show us the numbers?
> 
>> Toeplitz hash takes at least 100 ns to hash 12 bytes (one iteration per
>> bit : 96 iterations)
>>
>> For IPv6 it is 3 times this, since we have to hash 36 bytes.
>>
>> I do not see how it can compete with skb_get_hash() that directly gives
>> skb->hash for local TCP flows.
>>
> 
> My guess is that this is not the bottleneck, something is happening
> behind the scene with out packets in Hyper-V host (e.g. re-distributing
> them to hardware queues?) but I don't know the internals, Microsoft
> folks could probably comment.
> 
> 
>> See commits b73c3d0e4f0e1961e15bec18720e48aabebe2109
>> ("net: Save TX flow hash in sock and set in skbuf on xmit")
>> and 877d1f6291f8e391237e324be58479a3e3a7407c
>> ("net: Set sk_txhash from a random number")
>>
>> I understand Microsoft loves Toeplitz, but this looks not well placed
>> here.
>>
>> I suspect there is another problem.
>>
>> Please share your numbers and test methodology, and the alternative
>> patch Simon tested so that we can double check it.
>>
> 
> Alternative patch which uses skb_get_hash() attached. Simon, could you
> please share the rest (environment, metodology, numbers) with us here?
> Thanks!
> 
>> Thanks.
>>
>> PS: For the time being this patch can probably be applied on -net tree,
>> as it fixes a real bug.
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch] staging: unisys: remove some dead code

[Dan Carpenter]

queue_delayed_work() returns bool, not negative error codes.  It returns
false if the work has already been queued or true otherwise.  Since
we don't care about that, we can just remove the test.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 07594f4..ff2bd077 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2310,13 +2310,8 @@ visorchipset_init(struct acpi_device *acpi_device)
}
most_recent_message_jiffies = jiffies;
poll_jiffies = POLLJIFFIES_CONTROLVMCHANNEL_FAST;
-   rc = queue_delayed_work(periodic_controlvm_workqueue,
-   _controlvm_work, poll_jiffies);
-   if (rc < 0) {
-   POSTCODE_LINUX_2(QUEUE_DELAYED_WORK_PC,
-DIAG_SEVERITY_ERR);
-   goto cleanup;
-   }
+   queue_delayed_work(periodic_controlvm_workqueue,
+  _controlvm_work, poll_jiffies);
 
visorchipset_platform_device.dev.devt = major_dev;
if (platform_device_register(_platform_device) < 0) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: wlan-ng: p80211conv.c: Coding style fixes General coding style checks have been fixed. Warnings not fixed.

[Dan Carpenter]

You're going to have to split this into multiple patches that fix one
type of bug at a time.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

[Eric Dumazet]

On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
>  VLAN ID to flow_keys")) introduced a performance regression in netvsc
> driver. Is problem is, however, not the above mentioned commit but the
> fact that netvsc_set_hash() function did some assumptions on the struct
> flow_keys data layout and this is wrong. We need to extract the data we
> need (src/dst addresses and ports) after the dissect.
> 
> The issue could also be solved in a completely different way: as suggested
> by Eric instead of our own homegrown netvsc_set_hash() we could use
> skb_get_hash() which does more or less the same. Unfortunately, the
> testing done by Simon showed that Hyper-V hosts are not happy with our
> Jenkins hash, selecting the output queue with the current algorithm based
> on Toeplitz hash works significantly better.

Were tests done on IPv6 traffic ?

Toeplitz hash takes at least 100 ns to hash 12 bytes (one iteration per
bit : 96 iterations)

For IPv6 it is 3 times this, since we have to hash 36 bytes.

I do not see how it can compete with skb_get_hash() that directly gives
skb->hash for local TCP flows.

See commits b73c3d0e4f0e1961e15bec18720e48aabebe2109
("net: Save TX flow hash in sock and set in skbuf on xmit")
and 877d1f6291f8e391237e324be58479a3e3a7407c
("net: Set sk_txhash from a random number")

I understand Microsoft loves Toeplitz, but this looks not well placed
here.

I suspect there is another problem.

Please share your numbers and test methodology, and the alternative
patch Simon tested so that we can double check it.

Thanks.

PS: For the time being this patch can probably be applied on -net tree,
as it fixes a real bug.



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv2 1/1] staging/ion: Add support to get ion handle from dma buf

[Sumit Semwal]

Hi Rohit,

On 6 January 2016 at 12:41, Rohit kumar  wrote:
> Currently we can only import dma buf fd's to get ion_handle.
> Adding support to import dma buf handles to support kernel
> specific use cases.
>
> An example use case is in linux platforms such as Tizen, in which
> DRM-GEM is used for buffer management for graphics. It has gem_handle
> corresponding to a buffer and uses gem_name for sharing the buffer
> with other processes. However,it also uses dma_buf fd for 3d operations.
> For wayland, there are multiple calls for gem_handle to dma_buf fd
> conversion. So, we store dma_buf associated with buffer. But, there is
> no api for getting ion_handle from dma_buf. This patch exposes api to
> retrieve the ion handle from dma_buf for similar use cases. With this
> patch, we can integrate ION within DRM-GEM for buffer management and
> dma_buf sharing.
>
> Signed-off-by: Rohit kumar 
> ---
> v2: Updated commit message with use case explanation, as suggested by
> Laura Abbott
>
Thanks for this patch.

In general it looks good to me, but perhaps you should add related ION
tests for this as well? Once you add that and share for review, feel
free to add
Reviewed-by: Sumit Semwal 

>  drivers/staging/android/ion/ion.c |   21 +++--
>  drivers/staging/android/ion/ion.h |   20 
>  2 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index e237e9f..5509716 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
> struct ion_handle *handle)
>  }
>  EXPORT_SYMBOL(ion_share_dma_buf_fd);
>
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf)
>  {
> -   struct dma_buf *dmabuf;
> struct ion_buffer *buffer;
> struct ion_handle *handle;
> int ret;
>
> -   dmabuf = dma_buf_get(fd);
> -   if (IS_ERR(dmabuf))
> -   return ERR_CAST(dmabuf);
> /* if this memory came from ion */
>
> if (dmabuf->ops != _buf_ops) {
> @@ -1199,6 +1196,18 @@ end:
>  }
>  EXPORT_SYMBOL(ion_import_dma_buf);
>
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
> +{
> +   struct dma_buf *dmabuf;
> +
> +   dmabuf = dma_buf_get(fd);
> +   if (IS_ERR(dmabuf))
> +   return ERR_CAST(dmabuf);
> +
> +   return ion_import_dma_buf(client, dmabuf);
> +}
> +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> +
>  static int ion_sync_for_device(struct ion_client *client, int fd)
>  {
> struct dma_buf *dmabuf;
> @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
> {
> struct ion_handle *handle;
>
> -   handle = ion_import_dma_buf(client, data.fd.fd);
> +   handle = ion_import_dma_buf_fd(client, data.fd.fd);
> if (IS_ERR(handle))
> ret = PTR_ERR(handle);
> else
> diff --git a/drivers/staging/android/ion/ion.h 
> b/drivers/staging/android/ion/ion.h
> index b860c5f..a1331fc 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
> *client,
>  int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle 
> *handle);
>
>  /**
> - * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get 
> handle
> + * ion_import_dma_buf() - get ion_handle from dma-buf
> + * @client:the client
> + * @dmabuf:the dma-buf
> + *
> + * Get the ion_buffer associated with the dma-buf and return the ion_handle.
> + * If no ion_handle exists for this buffer, return newly created ion_handle.
> + * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
> + */
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf);
> +
> +/**
> + * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get 
> handle
>   * @client:the client
>   * @fd:the dma-buf fd
>   *
> - * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
> - * import that fd and return a handle representing it.  If a dma-buf from
> + * Given an dma-buf fd that was allocated through ion via 
> ion_share_dma_buf_fd,
> + * import that fd and return a handle representing it. If a dma-buf from
>   * another exporter is passed in this function will return ERR_PTR(-EINVAL)
>   */
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd);
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client 

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

[KY Srinivasan]

> -Original Message-
> From: John Fastabend [mailto:john.fastab...@gmail.com]
> Sent: Thursday, January 7, 2016 5:02 PM
> To: Vitaly Kuznetsov ; Simon Xiao
> ; Eric Dumazet 
> Cc: Tom Herbert ; net...@vger.kernel.org; KY
> Srinivasan ; Haiyang Zhang ;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; David Miller
> 
> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct
> flow_keys layout
> 
> On 16-01-07 05:28 AM, Vitaly Kuznetsov wrote:
> > Eric Dumazet  writes:
> >
> >> On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> >>> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
> >>>  VLAN ID to flow_keys")) introduced a performance regression in netvsc
> >>> driver. Is problem is, however, not the above mentioned commit but the
> >>> fact that netvsc_set_hash() function did some assumptions on the struct
> >>> flow_keys data layout and this is wrong. We need to extract the data we
> >>> need (src/dst addresses and ports) after the dissect.
> >>>
> >>> The issue could also be solved in a completely different way: as suggested
> >>> by Eric instead of our own homegrown netvsc_set_hash() we could use
> >>> skb_get_hash() which does more or less the same. Unfortunately, the
> >>> testing done by Simon showed that Hyper-V hosts are not happy with our
> >>> Jenkins hash, selecting the output queue with the current algorithm based
> >>> on Toeplitz hash works significantly better.
> >>
> 
> Also can I ask the maybe naive question. It looks like the hypervisor
> is populating some table via a mailbox msg and this is used to select
> the queues I guess with some sort of weighting function?
> 
> What happens if you just remove select_queue altogether? Or maybe just
> what is this 16 entry table doing? How does this work on my larger
> systems with 64+ cores can I only use 16 cores? Sorry I really have
> no experience with hyperV and this got me curious.

We will limit the number of VRSS channels to the number of CPUs in
a NUMA node. If the number of CPUs in a NUMA node exceeds 8, we
will only open up 8 VRSS channels. On the host side currently traffic
spreading is done in software and we have found that limiting to 8 CPUs
gives us the best throughput. In Windows Server 2016, we will be 
distributing traffic on the host in hardware; the heuristics in the guest
may change.

Regards,

K. Y
> 
> Thanks,
> John
> 
> >> Were tests done on IPv6 traffic ?
> >>
> >
> > Simon, could you please test this patch for IPv6 and show us the numbers?
> >
> >> Toeplitz hash takes at least 100 ns to hash 12 bytes (one iteration per
> >> bit : 96 iterations)
> >>
> >> For IPv6 it is 3 times this, since we have to hash 36 bytes.
> >>
> >> I do not see how it can compete with skb_get_hash() that directly gives
> >> skb->hash for local TCP flows.
> >>
> >
> > My guess is that this is not the bottleneck, something is happening
> > behind the scene with out packets in Hyper-V host (e.g. re-distributing
> > them to hardware queues?) but I don't know the internals, Microsoft
> > folks could probably comment.
> >
> >
> >> See commits b73c3d0e4f0e1961e15bec18720e48aabebe2109
> >> ("net: Save TX flow hash in sock and set in skbuf on xmit")
> >> and 877d1f6291f8e391237e324be58479a3e3a7407c
> >> ("net: Set sk_txhash from a random number")
> >>
> >> I understand Microsoft loves Toeplitz, but this looks not well placed
> >> here.
> >>
> >> I suspect there is another problem.
> >>
> >> Please share your numbers and test methodology, and the alternative
> >> patch Simon tested so that we can double check it.
> >>
> >
> > Alternative patch which uses skb_get_hash() attached. Simon, could you
> > please share the rest (environment, metodology, numbers) with us here?
> > Thanks!
> >
> >> Thanks.
> >>
> >> PS: For the time being this patch can probably be applied on -net tree,
> >> as it fixes a real bug.
> >

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] staging: unisys: remove some dead code

[Don Zickus]

On Thu, Jan 07, 2016 at 12:34:13PM +0300, Dan Carpenter wrote:
> queue_delayed_work() returns bool, not negative error codes.  It returns
> false if the work has already been queued or true otherwise.  Since
> we don't care about that, we can just remove the test.
> 
> Signed-off-by: Dan Carpenter 

Acked-by: Don Zickus 


> 
> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
> b/drivers/staging/unisys/visorbus/visorchipset.c
> index 07594f4..ff2bd077 100644
> --- a/drivers/staging/unisys/visorbus/visorchipset.c
> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
> @@ -2310,13 +2310,8 @@ visorchipset_init(struct acpi_device *acpi_device)
>   }
>   most_recent_message_jiffies = jiffies;
>   poll_jiffies = POLLJIFFIES_CONTROLVMCHANNEL_FAST;
> - rc = queue_delayed_work(periodic_controlvm_workqueue,
> - _controlvm_work, poll_jiffies);
> - if (rc < 0) {
> - POSTCODE_LINUX_2(QUEUE_DELAYED_WORK_PC,
> -  DIAG_SEVERITY_ERR);
> - goto cleanup;
> - }
> + queue_delayed_work(periodic_controlvm_workqueue,
> +_controlvm_work, poll_jiffies);
>  
>   visorchipset_platform_device.dev.devt = major_dev;
>   if (platform_device_register(_platform_device) < 0) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/2] Staging: goldfish: Add space around +

[Shraddha Barke]

Fix checkpatch warning of adding space around + in accordance with
kernel coding style.

Signed-off-by: Shraddha Barke 
---
Changes in v2-
 No change. Added lkml and other maintainers.

 drivers/staging/goldfish/goldfish_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/goldfish/goldfish_audio.c 
b/drivers/staging/goldfish/goldfish_audio.c
index b0927e4..f1e1838 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -63,7 +63,7 @@ struct goldfish_audio {
 #define AUDIO_READ(data, addr) (readl(data->reg_base + addr))
 #define AUDIO_WRITE(data, addr, x) (writel(x, data->reg_base + addr))
 #define AUDIO_WRITE64(data, addr, addr2, x)\
-   (gf_write_dma_addr((x), data->reg_base + addr, data->reg_base+addr2))
+   (gf_write_dma_addr((x), data->reg_base + addr, data->reg_base + addr2))
 
 /*
  *  temporary variable used between goldfish_audio_probe() and
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/2] Staging: goldfish: Checkpatch cleanups

[Shraddha Barke]

These patches remove the last few checkpatch warnings in staging/goldfish 
directory

Shraddha Barke (2):
  Staging: goldfish: Add space around +
  Staging: goldfish: Remove explicit NULL comparison

 drivers/staging/goldfish/goldfish_audio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

[John Fastabend]

On 16-01-07 07:49 PM, KY Srinivasan wrote:
> 
> 
>> -Original Message-
>> From: John Fastabend [mailto:john.fastab...@gmail.com]
>> Sent: Thursday, January 7, 2016 5:02 PM
>> To: Vitaly Kuznetsov ; Simon Xiao
>> ; Eric Dumazet 
>> Cc: Tom Herbert ; net...@vger.kernel.org; KY
>> Srinivasan ; Haiyang Zhang ;
>> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; David Miller
>> 
>> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct
>> flow_keys layout
>>
>> On 16-01-07 05:28 AM, Vitaly Kuznetsov wrote:
>>> Eric Dumazet  writes:
>>>
 On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
>  VLAN ID to flow_keys")) introduced a performance regression in netvsc
> driver. Is problem is, however, not the above mentioned commit but the
> fact that netvsc_set_hash() function did some assumptions on the struct
> flow_keys data layout and this is wrong. We need to extract the data we
> need (src/dst addresses and ports) after the dissect.
>
> The issue could also be solved in a completely different way: as suggested
> by Eric instead of our own homegrown netvsc_set_hash() we could use
> skb_get_hash() which does more or less the same. Unfortunately, the
> testing done by Simon showed that Hyper-V hosts are not happy with our
> Jenkins hash, selecting the output queue with the current algorithm based
> on Toeplitz hash works significantly better.

>>
>> Also can I ask the maybe naive question. It looks like the hypervisor
>> is populating some table via a mailbox msg and this is used to select
>> the queues I guess with some sort of weighting function?
>>
>> What happens if you just remove select_queue altogether? Or maybe just
>> what is this 16 entry table doing? How does this work on my larger
>> systems with 64+ cores can I only use 16 cores? Sorry I really have
>> no experience with hyperV and this got me curious.
> 
> We will limit the number of VRSS channels to the number of CPUs in
> a NUMA node. If the number of CPUs in a NUMA node exceeds 8, we
> will only open up 8 VRSS channels. On the host side currently traffic
> spreading is done in software and we have found that limiting to 8 CPUs
> gives us the best throughput. In Windows Server 2016, we will be 
> distributing traffic on the host in hardware; the heuristics in the guest
> may change.
> 
> Regards,
> 
> K. Y

I think a better way to do this would be to query the numa node when
the interface comes online via dev_to_node() and then use cpu_to_node()
or create/find some better variant to get a list of cpus on the numa
node.

At this point you can use the xps mapping interface
netif_set_xps_queue() to get the right queue to cpu binding. If you want
to cap it to max 8 queues that works as well. I don't think there is
any value to have more tx queues than number of cpus in use.

If you do it this way all the normal mechanisms to setup queue mappings
will work for users who are doing some special configuration and the
default will still be what you want.

I guess I should go do this numa mapping for ixgbe and friends now that
I mention it. Last perf numbers I had showed cross numa affinitizing
was pretty bad.

Thanks,
John

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv2 1/1] staging/ion: Add support to get ion handle from dma buf

[Rohit]

Hi Sumit,

On Thu, 07 Jan 2016 19:43:09 +0530
Sumit Semwal  wrote:

> Hi Rohit,
> 
> On 6 January 2016 at 12:41, Rohit kumar  wrote:
> > Currently we can only import dma buf fd's to get ion_handle.
> > Adding support to import dma buf handles to support kernel
> > specific use cases.
> >
> > An example use case is in linux platforms such as Tizen, in which
> > DRM-GEM is used for buffer management for graphics. It has
> > gem_handle corresponding to a buffer and uses gem_name for sharing
> > the buffer with other processes. However,it also uses dma_buf fd
> > for 3d operations. For wayland, there are multiple calls for
> > gem_handle to dma_buf fd conversion. So, we store dma_buf
> > associated with buffer. But, there is no api for getting ion_handle
> > from dma_buf. This patch exposes api to retrieve the ion handle
> > from dma_buf for similar use cases. With this patch, we can
> > integrate ION within DRM-GEM for buffer management and dma_buf
> > sharing.
> >
> > Signed-off-by: Rohit kumar 
> > ---
> > v2: Updated commit message with use case explanation, as suggested
> > by Laura Abbott
> >
> Thanks for this patch.
> 
> In general it looks good to me, but perhaps you should add related ION
> tests for this as well? Once you add that and share for review, feel
> free to add
Thanks for the suggestion. I would add related ION test and share for
review sooner.
> Reviewed-by: Sumit Semwal 
> 
> >  drivers/staging/android/ion/ion.c |   21 +++--
> >  drivers/staging/android/ion/ion.h |   20 
> >  2 files changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index e237e9f..5509716 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle) }
> >  EXPORT_SYMBOL(ion_share_dma_buf_fd);
> >
> > -struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> > int fd) +struct ion_handle *ion_import_dma_buf(struct ion_client
> > *client,
> > + struct dma_buf *dmabuf)
> >  {
> > -   struct dma_buf *dmabuf;
> > struct ion_buffer *buffer;
> > struct ion_handle *handle;
> > int ret;
> >
> > -   dmabuf = dma_buf_get(fd);
> > -   if (IS_ERR(dmabuf))
> > -   return ERR_CAST(dmabuf);
> > /* if this memory came from ion */
> >
> > if (dmabuf->ops != _buf_ops) {
> > @@ -1199,6 +1196,18 @@ end:
> >  }
> >  EXPORT_SYMBOL(ion_import_dma_buf);
> >
> > +struct ion_handle *ion_import_dma_buf_fd(struct ion_client
> > *client, int fd) +{
> > +   struct dma_buf *dmabuf;
> > +
> > +   dmabuf = dma_buf_get(fd);
> > +   if (IS_ERR(dmabuf))
> > +   return ERR_CAST(dmabuf);
> > +
> > +   return ion_import_dma_buf(client, dmabuf);
> > +}
> > +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> > +
> >  static int ion_sync_for_device(struct ion_client *client, int fd)
> >  {
> > struct dma_buf *dmabuf;
> > @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp,
> > unsigned int cmd, unsigned long arg) {
> > struct ion_handle *handle;
> >
> > -   handle = ion_import_dma_buf(client, data.fd.fd);
> > +   handle = ion_import_dma_buf_fd(client, data.fd.fd);
> > if (IS_ERR(handle))
> > ret = PTR_ERR(handle);
> > else
> > diff --git a/drivers/staging/android/ion/ion.h
> > b/drivers/staging/android/ion/ion.h index b860c5f..a1331fc 100644
> > --- a/drivers/staging/android/ion/ion.h
> > +++ b/drivers/staging/android/ion/ion.h
> > @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct
> > ion_client *client, int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle);
> >
> >  /**
> > - * ion_import_dma_buf() - given an dma-buf fd from the ion
> > exporter get handle
> > + * ion_import_dma_buf() - get ion_handle from dma-buf
> > + * @client:the client
> > + * @dmabuf:the dma-buf
> > + *
> > + * Get the ion_buffer associated with the dma-buf and return the
> > ion_handle.
> > + * If no ion_handle exists for this buffer, return newly created
> > ion_handle.
> > + * If dma-buf from another exporter is passed, return
> > ERR_PTR(-EINVAL)
> > + */
> > +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> > + struct dma_buf *dmabuf);
> > +
> > +/**
> > + * ion_import_dma_buf_fd() - given a dma-buf fd from the ion
> > exporter get handle
> >   * @client:the client
> >   * @fd:the dma-buf fd
> >   *
> > - * Given an dma-buf fd that was allocated through ion via
> > ion_share_dma_buf,
> > - * import that fd and return a handle representing it.  If a
> > 

[PATCH 06/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Logical continuation is fixed

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index c9bbf89..44bf164 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -200,8 +200,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

p80211_wep->data = NULL;

-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED)
-   && (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
/*  need to pick keynum other than default? */

p80211_wep->data = kmalloc(skb->len, GFP_ATOMIC);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 08/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Removed blank line after open braces

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 2c251e3..27342f8 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -239,7 +239,6 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
 * source address with out list, and if match, get the stats... */

for (i = 0; i < wlandev->spy_number; i++) {
-
if (!memcmp(wlandev->spy_address[i], mac, ETH_ALEN)) {
memcpy(wlandev->spy_address[i], mac, ETH_ALEN);
wlandev->spy_stat[i].level = rxmeta->signal;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 10/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Logical continuation fixing for 'if' block

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 32039ae..d3ee4f2 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -297,8 +297,8 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
if ((WLAN_GET_FC_TODS(fc) == 0) && (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a2);
-   } else if ((WLAN_GET_FC_TODS(fc) == 0)
-   && (WLAN_GET_FC_FROMDS(fc) == 1)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 0) &&
+  (WLAN_GET_FC_FROMDS(fc) == 1)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a3);
} else if ((WLAN_GET_FC_TODS(fc) == 1)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 11/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Logical continuation fix for 'if' block

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index d3ee4f2..28d7fd8 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -301,8 +301,8 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
   (WLAN_GET_FC_FROMDS(fc) == 1)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a3);
-   } else if ((WLAN_GET_FC_TODS(fc) == 1)
-   && (WLAN_GET_FC_FROMDS(fc) == 0)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 1) &&
+  (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a3);
ether_addr_copy(saddr, w_hdr->a3.a2);
} else {
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 05/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Removed blank line after braces

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index d799701..c9bbf89 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -166,7 +166,6 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
e_llc->dsap = 0xAA; /* SNAP, see IEEE 802 */
e_llc->ssap = 0xAA;
e_llc->ctl = 0x03;
-
}
}

--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 07/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Alignment matched with open parenthesis

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 44bf164..2c251e3 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -213,8 +213,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
  p80211_wep->iv, p80211_wep->icv);
if (foo) {
netdev_warn(wlandev->netdev,
-  "Host en-WEP failed, dropping frame (%d).\n",
-  foo);
+   "Host en-WEP failed, dropping frame 
(%d).\n",
+   foo);
return 2;
}
fc |= cpu_to_le16(WLAN_SET_FC_ISWEP(1));
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 03/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Fixed a logical continuation

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 4bcc444..ff5a2cc 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -150,8 +150,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
(struct wlan_snap *)skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
-   if (ethconv == WLAN_ETHCONV_8021h
-   && p80211_stt_findproto(proto)) {
+   if (ethconv == WLAN_ETHCONV_8021h &&
+   p80211_stt_findproto(proto)) {
memcpy(e_snap->oui, oui_8021h,
   WLAN_IEEE_OUI_LEN);
} else {
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 02/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Removed space after casting

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 7e3d4b5..4bcc444 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -147,7 +147,7 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

/* tack on SNAP */
e_snap =
-   (struct wlan_snap *) skb_push(skb,
+   (struct wlan_snap *)skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
if (ethconv == WLAN_ETHCONV_8021h
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 14/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Removed space after casting operator

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 7369a1b..45411d9 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -348,7 +348,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
wlandev->rx.decrypt++;
}

-   e_hdr = (struct wlan_ethhdr *) (skb->data + payload_offset);
+   e_hdr = (struct wlan_ethhdr *)(skb->data + payload_offset);

e_llc = (struct wlan_llc *) (skb->data + payload_offset);
e_snap =
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 15/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Removed space after casting operator

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 45411d9..a0f45d2 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -350,7 +350,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,

e_hdr = (struct wlan_ethhdr *)(skb->data + payload_offset);

-   e_llc = (struct wlan_llc *) (skb->data + payload_offset);
+   e_llc = (struct wlan_llc *)(skb->data + payload_offset);
e_snap =
(struct wlan_snap *) (skb->data + payload_offset +
sizeof(struct wlan_llc));
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 12/40] drivers/staging/wlan-ng/p80211conv.c: Fixed coding style

[Pranjal Bhor]

Logical continuation fix for 'if' block

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 28d7fd8..8769e47 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -317,8 +317,9 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
}

/* perform de-wep if necessary.. */
-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) && WLAN_GET_FC_ISWEP(fc)
-   && (wlandev->hostwep & HOSTWEP_DECRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   WLAN_GET_FC_ISWEP(fc) &&
+   (wlandev->hostwep & HOSTWEP_DECRYPT)) {
if (payload_length <= 8) {
netdev_err(netdev,
   "WEP frame too short (%u).\n", skb->len);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 01/40] drivers/stagin/wlan-ng/p80211conv.c: Fix coding style

[Dan Carpenter]

You can't have 40 patches with the same subject.  Also that is too
generic a subject.

Also don't break it up into one line per patch, break it up so it's
patch 1: remove blank lines
patch 2: no spaces after a cast
patch 3: fix all NULL compares

etc...

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel