Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1443535 > unrolled thread

Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Matt Wilson <msw@amzn.com> - 2016-07-14 17:30 +0200
    Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Benjamin Poirier <benjamin.poirier@gmail.com> - 2016-07-14 18:10 +0200
      Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Matt Wilson <msw@amzn.com> - 2016-07-14 18:20 +0200
        Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) David Miller <davem@davemloft.net> - 2016-07-15 20:30 +0200

#1443535 — Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Thu, Jul 14, 2016 at 09:46:14AM +0300, Netanel Belgazal wrote:
> This is a driver for the ENA family of networking devices.
> 
> Signed-off-by: Netanel Belgazal <netanel@annapurnalabs.com>
> ---
> 
> Notes:
>     Changes in v3:
>     - Fix compilation warning for 32bit systems. [kbuild test rebot]
>     - Replace netdev->num_tx_queues with adapter->num_queues in ethtool. [ben@decadent.org.uk]
>     - Use get_link_ksettings instread of get_settings (deprecated ethtool API). [ben@decadent.org.uk]
>     - Remove rna_nway_reset (ethtool). [ben@decadent.org.uk]
>     - Add missing break in switch condition. [ben@decadent.org.uk]
>     - Increase driver version to 1.0.2
>     
>     Changes in v2:
>     - Increment driver version to 1.0.1
>     - Reorder the initialization of the workqueus and the timer service
>     - Initialize last_keep_alive_jiffies in probe
>     - Remove ena_trc_* functions in favor of pr_* [davem@davemloft.net]
>     - Fix Tx interrupt control register value [romieu@fr.zoreil.com]
>     - Edit ena.txt to focus on technical details [romieu@fr.zoreil.com]
>     - Rename small_copy_len tunable to rx_copybreak [benjamin.poirier@gmail.com]
>     - Change uint32_t to u32 [romieu@fr.zoreil.com]
>     - Return error in ena_com_set_hash_ctrl [rami.rosen@intel.com]
>     - Fix API documentation [rami.rosen@intel.com]
>     - Remove redundant check in ena_com_mem_addr_set [romieu@fr.zoreil.com]
>     - Add local variables for allocation methods to improve readability [romieu@fr.zoreil.com]
>     - Replace dma_alloc_coherent and __GFP_ZERO flag with dma_zalloc_coherent [romieu@fr.zoreil.com]
>     - Fix style when using dma_alloc_coherent [romieu@fr.zoreil.com]
>     - Tx xmit - In case of an error drop the packet and return NETDEV_TX_OK [romieu@fr.zoreil.com]
>     - Reduce the number of parameters in ena_get_dev_stats [romieu@fr.zoreil.com]
>     - Return ret and not 0 in ena_com_set_hash_ctrl [rami.rosen@intel.com]
>     - Do not initialize variables if the function doesn't read them before the second write [romieu@fr.zoreil.com]
>     - Enums - Replace space with tabs to line the assign value [romieu@fr.zoreil.com]
>     - Remove redundant comments [romieu@fr.zoreil.com]
>     
>     TODO:
>     - Add bytes variable to set_coalesce ethtool callback and use this callback
>       instead of dedicated sysfs files.

Dave and Benjamin,

Do you want to see the interrupt moderation extensions to ethtool and
the sysfs nodes removed before this lands in net-next? Or should
Netanel remove the sysfs bits until we can extend the ethtool
interfaces to cover the parameters that ena uses?

--msw

[toc] | [next] | [standalone]

#1443554

On 2016/07/14 08:22, Matt Wilson wrote:
[...]
> 
> Dave and Benjamin,
> 
> Do you want to see the interrupt moderation extensions to ethtool and
> the sysfs nodes removed before this lands in net-next? Or should
> Netanel remove the sysfs bits until we can extend the ethtool
> interfaces to cover the parameters that ena uses?

I couldn't say what's acceptable or not. A few other drivers (qlcnic,
sfc, ...) already have sysfs tunables. Maybe John, as the new ethtool
maintainer, can weight in too about the changes required to ethtool.

[toc] | [prev] | [next] | [standalone]

#1443571

On Thu, Jul 14, 2016 at 09:08:03AM -0700, Benjamin Poirier wrote:
> On 2016/07/14 08:22, Matt Wilson wrote:
> [...]
> > 
> > Dave and Benjamin,
> > 
> > Do you want to see the interrupt moderation extensions to ethtool and
> > the sysfs nodes removed before this lands in net-next? Or should
> > Netanel remove the sysfs bits until we can extend the ethtool
> > interfaces to cover the parameters that ena uses?
> 
> I couldn't say what's acceptable or not. A few other drivers (qlcnic,
> sfc, ...) already have sysfs tunables. Maybe John, as the new ethtool
> maintainer, can weight in too about the changes required to ethtool.

We definitely want ethtool to handle all the settings, it's just a
question of when. We also want to address and resolve all the great
feedback so far, and since you originally raised the point about
extending ethtool I wanted to see if you have any major objection.

--msw

[toc] | [prev] | [next] | [standalone]

#1444501

From: Matt Wilson <msw@amzn.com>
Date: Thu, 14 Jul 2016 09:15:11 -0700

> On Thu, Jul 14, 2016 at 09:08:03AM -0700, Benjamin Poirier wrote:
>> On 2016/07/14 08:22, Matt Wilson wrote:
>> [...]
>> > 
>> > Dave and Benjamin,
>> > 
>> > Do you want to see the interrupt moderation extensions to ethtool and
>> > the sysfs nodes removed before this lands in net-next? Or should
>> > Netanel remove the sysfs bits until we can extend the ethtool
>> > interfaces to cover the parameters that ena uses?
>> 
>> I couldn't say what's acceptable or not. A few other drivers (qlcnic,
>> sfc, ...) already have sysfs tunables. Maybe John, as the new ethtool
>> maintainer, can weight in too about the changes required to ethtool.
> 
> We definitely want ethtool to handle all the settings, it's just a
> question of when. We also want to address and resolve all the great
> feedback so far, and since you originally raised the point about
> extending ethtool I wanted to see if you have any major objection.

If you add the sysfs stuff you're stuck with it forever, so I definitely
do not want to see that.

You guys should start simple, a basic driver that supports what is
possible with no core kernel changes or non-portable driver private
sysfs knobx.  Only then should you think about adding new things.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web