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

Groups > linux.kernel > #1443945 > unrolled thread

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

Started byLeon Romanovsky <leon@kernel.org>
First post2016-07-15 07:10 +0200
Last post2016-07-19 20:40 +0200
Articles 8 — 4 participants

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) Leon Romanovsky <leon@kernel.org> - 2016-07-15 07:10 +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-15 17:20 +0200
      Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Leon Romanovsky <leon@kernel.org> - 2016-07-15 17:50 +0200
    Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Netanel Belgazal <netanel@annapurnalabs.com> - 2016-07-19 13:10 +0200
      Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Leon Romanovsky <leon@kernel.org> - 2016-07-19 19:30 +0200
        Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Joe Perches <joe@perches.com> - 2016-07-19 20:00 +0200
          Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Leon Romanovsky <leon@kernel.org> - 2016-07-25 07:10 +0200
        Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic  Network Adapters (ENA) Netanel Belgazal <netanel@annapurnalabs.com> - 2016-07-19 20:40 +0200

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

FromLeon Romanovsky <leon@kernel.org>
Date2016-07-15 07:10 +0200
SubjectRe: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)
Message-ID<rV3xU-2IL-7@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

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:

...

>     - Increase driver version to 1.0.2

...

> +static void ena_get_drvinfo(struct net_device *dev,
> +			    struct ethtool_drvinfo *info)
> +{
> +	struct ena_adapter *adapter = netdev_priv(dev);
> +
> +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));

Does module version give anything valuable in real life usage?
Do you plan to bump version after every patch?

Hint, NO.

> +	strlcpy(info->bus_info, pci_name(adapter->pdev),
> +		sizeof(info->bus_info));
> +}
> +
> +

...

> +
> +static char version[] =
> +		DEVICE_NAME " v"
> +		DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
> +
> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
> +MODULE_DESCRIPTION(DEVICE_NAME);
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION(DRV_MODULE_VERSION);
> +
> +/* Time in jiffies before concluding the transmitter is hung. */
> +#define TX_TIMEOUT  (5 * HZ)
> +
> +#define ENA_NAPI_BUDGET 64
> +
> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | \
> +		NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
> +static int debug = -1;
> +module_param(debug, int, 0);
> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");

What is it?

> +
> +static int push_mode;
> +module_param(push_mode, int, 0);
> +MODULE_PARM_DESC(push_mode, "Descriptor / header push mode (0=automatic,1=disable,3=enable)\n"
> +		 "\t\t\t  0 - Automatically choose according to device capability (default)\n"
> +		 "\t\t\t  1 - Don't push anything to device memory\n"
> +		 "\t\t\t  3 - Push descriptors and header buffer to device memory");
> +
> +static int enable_wd = 1;
> +module_param(enable_wd, int, 0);
> +MODULE_PARM_DESC(enable_wd, "Enable keepalive watchdog (0=disable,1=enable,default=1)");
> +
> +static int enable_missing_tx_detection = 1;
> +module_param(enable_missing_tx_detection, int, 0);
> +MODULE_PARM_DESC(enable_missing_tx_detection, "Enable missing Tx completions. (default=1)");
> +
> +static int numa_node_override_array[NR_CPUS] = {[0 ... (NR_CPUS - 1)] = NUMA_NO_NODE };
> +module_param_array(numa_node_override_array, int, NULL, 0);
> +MODULE_PARM_DESC(numa_node_override_array, "Numa node override map\n");
> +
> +static int numa_node_override;
> +module_param(numa_node_override, int, 0);
> +MODULE_PARM_DESC(numa_node_override, "Enable/Disable numa node override (0=disable)\n");

As fas as I remember, new drivers are not supposed to add module
parameters.

...

> +
> +#define DRV_MODULE_VER_MAJOR	1
> +#define DRV_MODULE_VER_MINOR	0
> +#define DRV_MODULE_VER_SUBMINOR 1
> +
> +#define DRV_MODULE_NAME		"ena"
> +#ifndef DRV_MODULE_VERSION
> +#define DRV_MODULE_VERSION \
> +	__stringify(DRV_MODULE_VER_MAJOR) "."	\
> +	__stringify(DRV_MODULE_VER_MINOR) "."	\
> +	__stringify(DRV_MODULE_VER_SUBMINOR)
> +#endif
> +#define DRV_MODULE_RELDATE      "22-JUNE-2016"

Please remove it, driver version is useless in real life kernel usage.

[toc] | [next] | [standalone]

#1444364

FromBenjamin Poirier <benjamin.poirier@gmail.com>
Date2016-07-15 17:20 +0200
Message-ID<rVd4e-8vN-17@gated-at.bofh.it>
In reply to#1443945

[Multipart message — attachments visible in raw view] — view raw

On 2016/07/15 08:00, Leon Romanovsky wrote:
> 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:
> 
> ...
> 
> >     - Increase driver version to 1.0.2
> 
> ...
> 
> > +static void ena_get_drvinfo(struct net_device *dev,
> > +			    struct ethtool_drvinfo *info)
> > +{
> > +	struct ena_adapter *adapter = netdev_priv(dev);
> > +
> > +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> > +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
> 
> Does module version give anything valuable in real life usage?
> Do you plan to bump version after every patch?
> 
> Hint, NO.
> 
[...]
> > +
> > +#define DRV_MODULE_VER_MAJOR	1
> > +#define DRV_MODULE_VER_MINOR	0
> > +#define DRV_MODULE_VER_SUBMINOR 1
> > +
> > +#define DRV_MODULE_NAME		"ena"
> > +#ifndef DRV_MODULE_VERSION
> > +#define DRV_MODULE_VERSION \
> > +	__stringify(DRV_MODULE_VER_MAJOR) "."	\
> > +	__stringify(DRV_MODULE_VER_MINOR) "."	\
> > +	__stringify(DRV_MODULE_VER_SUBMINOR)
> > +#endif
> > +#define DRV_MODULE_RELDATE      "22-JUNE-2016"
> 
> Please remove it, driver version is useless in real life kernel usage.
> 

The release date might be a bit overkill but the driver version is
useful in the context of distribution kernels where users sometimes mix
and match newer drivers (ex: the intel sf.net drivers) with older
kernels. When a bug is reported, a quick look at the module version can
help indicate the provenance of the driver.

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

#1444395

FromLeon Romanovsky <leon@kernel.org>
Date2016-07-15 17:50 +0200
Message-ID<rVdxg-dW-11@gated-at.bofh.it>
In reply to#1444364

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 15, 2016 at 08:17:59AM -0700, Benjamin Poirier wrote:
> On 2016/07/15 08:00, Leon Romanovsky wrote:
> > 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:
> > 
> > ...
> > 
> > >     - Increase driver version to 1.0.2
> > 
> > ...
> > 
> > > +static void ena_get_drvinfo(struct net_device *dev,
> > > +			    struct ethtool_drvinfo *info)
> > > +{
> > > +	struct ena_adapter *adapter = netdev_priv(dev);
> > > +
> > > +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> > > +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
> > 
> > Does module version give anything valuable in real life usage?
> > Do you plan to bump version after every patch?
> > 
> > Hint, NO.
> > 
> [...]
> > > +
> > > +#define DRV_MODULE_VER_MAJOR	1
> > > +#define DRV_MODULE_VER_MINOR	0
> > > +#define DRV_MODULE_VER_SUBMINOR 1
> > > +
> > > +#define DRV_MODULE_NAME		"ena"
> > > +#ifndef DRV_MODULE_VERSION
> > > +#define DRV_MODULE_VERSION \
> > > +	__stringify(DRV_MODULE_VER_MAJOR) "."	\
> > > +	__stringify(DRV_MODULE_VER_MINOR) "."	\
> > > +	__stringify(DRV_MODULE_VER_SUBMINOR)
> > > +#endif
> > > +#define DRV_MODULE_RELDATE      "22-JUNE-2016"
> > 
> > Please remove it, driver version is useless in real life kernel usage.
> > 
> 
> The release date might be a bit overkill but the driver version is
> useful in the context of distribution kernels where users sometimes mix
> and match newer drivers (ex: the intel sf.net drivers) with older
> kernels. When a bug is reported, a quick look at the module version can
> help indicate the provenance of the driver.

We already discussed it in a number of occasions, for example this is
response of Greg Kroah-Hartman to similar attempt to bump driver version
[1].

And as I said before, mostly this driver will change without any
reflection in driver version.

[1] http://www.spinics.net/lists/linux-rdma/msg29855.html

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

#1446332

FromNetanel Belgazal <netanel@annapurnalabs.com>
Date2016-07-19 13:10 +0200
Message-ID<rWB4t-3hE-1@gated-at.bofh.it>
In reply to#1443945

On 07/15/2016 08:00 AM, Leon Romanovsky wrote:
> 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:
> ...
>
>>     - Increase driver version to 1.0.2
> ...
>
>> +static void ena_get_drvinfo(struct net_device *dev,
>> +			    struct ethtool_drvinfo *info)
>> +{
>> +	struct ena_adapter *adapter = netdev_priv(dev);
>> +
>> +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
>> +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
> Does module version give anything valuable in real life usage?
> Do you plan to bump version after every patch?
>
> Hint, NO.

I think it is appropriate to expose driver version to ethtool, and itis appropriate to be able to version a driver in upstream (mainly for debug purpose)
I don't think there is upstream agreementthat no driver should be allowed to maintain a versionnumber.

>> +	strlcpy(info->bus_info, pci_name(adapter->pdev),
>> +		sizeof(info->bus_info));
>> +}
>> +
>> +
> ...
>
>> +
>> +static char version[] =
>> +		DEVICE_NAME " v"
>> +		DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
>> +
>> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
>> +MODULE_DESCRIPTION(DEVICE_NAME);
>> +MODULE_LICENSE("GPL");
>> +MODULE_VERSION(DRV_MODULE_VERSION);
>> +
>> +/* Time in jiffies before concluding the transmitter is hung. */
>> +#define TX_TIMEOUT  (5 * HZ)
>> +
>> +#define ENA_NAPI_BUDGET 64
>> +
>> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | \
>> +		NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
>> +static int debug = -1;
>> +module_param(debug, int, 0);
>> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
> What is it?

This is the debugging message interface.
https://www.kernel.org/doc/Documentation/networking/netif-msg.txt

>> +
>> +static int push_mode;
>> +module_param(push_mode, int, 0);
>> +MODULE_PARM_DESC(push_mode, "Descriptor / header push mode (0=automatic,1=disable,3=enable)\n"
>> +		 "\t\t\t  0 - Automatically choose according to device capability (default)\n"
>> +		 "\t\t\t  1 - Don't push anything to device memory\n"
>> +		 "\t\t\t  3 - Push descriptors and header buffer to device memory");
>> +
>> +static int enable_wd = 1;
>> +module_param(enable_wd, int, 0);
>> +MODULE_PARM_DESC(enable_wd, "Enable keepalive watchdog (0=disable,1=enable,default=1)");
>> +
>> +static int enable_missing_tx_detection = 1;
>> +module_param(enable_missing_tx_detection, int, 0);
>> +MODULE_PARM_DESC(enable_missing_tx_detection, "Enable missing Tx completions. (default=1)");
>> +
>> +static int numa_node_override_array[NR_CPUS] = {[0 ... (NR_CPUS - 1)] = NUMA_NO_NODE };
>> +module_param_array(numa_node_override_array, int, NULL, 0);
>> +MODULE_PARM_DESC(numa_node_override_array, "Numa node override map\n");
>> +
>> +static int numa_node_override;
>> +module_param(numa_node_override, int, 0);
>> +MODULE_PARM_DESC(numa_node_override, "Enable/Disable numa node override (0=disable)\n");
> As fas as I remember, new drivers are not supposed to add module
> parameters.
>
Ack, I'll remove those module params.

> ...
>
>> +
>> +#define DRV_MODULE_VER_MAJOR	1
>> +#define DRV_MODULE_VER_MINOR	0
>> +#define DRV_MODULE_VER_SUBMINOR 1
>> +
>> +#define DRV_MODULE_NAME		"ena"
>> +#ifndef DRV_MODULE_VERSION
>> +#define DRV_MODULE_VERSION \
>> +	__stringify(DRV_MODULE_VER_MAJOR) "."	\
>> +	__stringify(DRV_MODULE_VER_MINOR) "."	\
>> +	__stringify(DRV_MODULE_VER_SUBMINOR)
>> +#endif
>> +#define DRV_MODULE_RELDATE      "22-JUNE-2016"
> Please remove it, driver version is useless in real life kernel usage.
>

I'll remove the driver date.

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

#1446609

FromLeon Romanovsky <leon@kernel.org>
Date2016-07-19 19:30 +0200
Message-ID<rWH0d-6Rp-11@gated-at.bofh.it>
In reply to#1446332

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 19, 2016 at 02:09:25PM +0300, Netanel Belgazal wrote:
> 
> 
> On 07/15/2016 08:00 AM, Leon Romanovsky wrote:
> > 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:
> > ...
> >
> >>     - Increase driver version to 1.0.2
> > ...
> >
> >> +static void ena_get_drvinfo(struct net_device *dev,
> >> +			    struct ethtool_drvinfo *info)
> >> +{
> >> +	struct ena_adapter *adapter = netdev_priv(dev);
> >> +
> >> +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
> >> +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
> > Does module version give anything valuable in real life usage?
> > Do you plan to bump version after every patch?
> >
> > Hint, NO.
> 
> I think it is appropriate to expose driver version to ethtool, and itis appropriate to be able to version a driver in upstream (mainly for debug purpose)
> I don't think there is upstream agreementthat no driver should be allowed to maintain a versionnumber.

You didn't answer on my questions, so I suppose that this version
interface will be forgotten and won't be relevant after first major
rework.

You have kernel version to know which driver you are running, mixing
different versions of driver with other kernels are seeing as
not-supported by the community.

> 
> >> +	strlcpy(info->bus_info, pci_name(adapter->pdev),
> >> +		sizeof(info->bus_info));
> >> +}
> >> +
> >> +
> > ...
> >
> >> +
> >> +static char version[] =
> >> +		DEVICE_NAME " v"
> >> +		DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
> >> +
> >> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
> >> +MODULE_DESCRIPTION(DEVICE_NAME);
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_VERSION(DRV_MODULE_VERSION);
> >> +
> >> +/* Time in jiffies before concluding the transmitter is hung. */
> >> +#define TX_TIMEOUT  (5 * HZ)
> >> +
> >> +#define ENA_NAPI_BUDGET 64
> >> +
> >> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | \
> >> +		NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
> >> +static int debug = -1;
> >> +module_param(debug, int, 0);
> >> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
> > What is it?
> 
> This is the debugging message interface.
> https://www.kernel.org/doc/Documentation/networking/netif-msg.txt

This document was updated last time in 2006 and I doubt that it is
relevant in 2016. You have dynamic debug prints infrastructure for it,
use it.

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

#1446619

FromJoe Perches <joe@perches.com>
Date2016-07-19 20:00 +0200
Message-ID<rWHtg-72L-31@gated-at.bofh.it>
In reply to#1446609
On Tue, 2016-07-19 at 20:26 +0300, Leon Romanovsky wrote:
> On Tue, Jul 19, 2016 at 02:09:25PM +0300, Netanel Belgazal wrote:
> > This is the debugging message interface.
> > https://www.kernel.org/doc/Documentation/networking/netif-msg.txt
> This document was updated last time in 2006 and I doubt that it is
> relevant in 2016. You have dynamic debug prints infrastructure for it,
> use it.

I think this is uninformed.

netif_<level> works well, is compatible with dynamic debug,
and is commonly used with new networking drivers.

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

#1449283

FromLeon Romanovsky <leon@kernel.org>
Date2016-07-25 07:10 +0200
Message-ID<rYGjn-v0-1@gated-at.bofh.it>
In reply to#1446619

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 19, 2016 at 10:49:57AM -0700, Joe Perches wrote:
> On Tue, 2016-07-19 at 20:26 +0300, Leon Romanovsky wrote:
> > On Tue, Jul 19, 2016 at 02:09:25PM +0300, Netanel Belgazal wrote:
> > > This is the debugging message interface.
> > > https://www.kernel.org/doc/Documentation/networking/netif-msg.txt
> > This document was updated last time in 2006 and I doubt that it is
> > relevant in 2016. You have dynamic debug prints infrastructure for it,
> > use it.
> 
> I think this is uninformed.
> 
> netif_<level> works well, is compatible with dynamic debug,
> and is commonly used with new networking drivers.
> 

I have a very strong feeling that it is not "used in new drivers" by was
influenced (copied) from "old drivers". The same goes for real life usage of
module version which was introduced in this patch.

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

#1446656

FromNetanel Belgazal <netanel@annapurnalabs.com>
Date2016-07-19 20:40 +0200
Message-ID<rWI5X-7uZ-9@gated-at.bofh.it>
In reply to#1446609

On 07/19/2016 08:26 PM, Leon Romanovsky wrote:
> On Tue, Jul 19, 2016 at 02:09:25PM +0300, Netanel Belgazal wrote:
>>
>> On 07/15/2016 08:00 AM, Leon Romanovsky wrote:
>>> 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:
>>> ...
>>>
>>>>     - Increase driver version to 1.0.2
>>> ...
>>>
>>>> +static void ena_get_drvinfo(struct net_device *dev,
>>>> +			    struct ethtool_drvinfo *info)
>>>> +{
>>>> +	struct ena_adapter *adapter = netdev_priv(dev);
>>>> +
>>>> +	strlcpy(info->driver, DRV_MODULE_NAME, sizeof(info->driver));
>>>> +	strlcpy(info->version, DRV_MODULE_VERSION, sizeof(info->version));
>>> Does module version give anything valuable in real life usage?
>>> Do you plan to bump version after every patch?
>>>
>>> Hint, NO.
>> I think it is appropriate to expose driver version to ethtool, and itis appropriate to be able to version a driver in upstream (mainly for debug purpose)
>> I don't think there is upstream agreementthat no driver should be allowed to maintain a versionnumber.
> You didn't answer on my questions, so I suppose that this version
> interface will be forgotten and won't be relevant after first major
> rework.
>
> You have kernel version to know which driver you are running, mixing
> different versions of driver with other kernels are seeing as
> not-supported by the community.

We need this information for our internal purposes including debugging and problems tracking.
It is in our interests to make sure that versions are managed correctly.
Besides, it seems to be a common practice, and most of the drivers maintain internal driver versions.
   
>>>> +	strlcpy(info->bus_info, pci_name(adapter->pdev),
>>>> +		sizeof(info->bus_info));
>>>> +}
>>>> +
>>>> +
>>> ...
>>>
>>>> +
>>>> +static char version[] =
>>>> +		DEVICE_NAME " v"
>>>> +		DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
>>>> +
>>>> +MODULE_AUTHOR("Amazon.com, Inc. or its affiliates");
>>>> +MODULE_DESCRIPTION(DEVICE_NAME);
>>>> +MODULE_LICENSE("GPL");
>>>> +MODULE_VERSION(DRV_MODULE_VERSION);
>>>> +
>>>> +/* Time in jiffies before concluding the transmitter is hung. */
>>>> +#define TX_TIMEOUT  (5 * HZ)
>>>> +
>>>> +#define ENA_NAPI_BUDGET 64
>>>> +
>>>> +#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | \
>>>> +		NETIF_MSG_TX_DONE | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR)
>>>> +static int debug = -1;
>>>> +module_param(debug, int, 0);
>>>> +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
>>> What is it?
>> This is the debugging message interface.
>> https://www.kernel.org/doc/Documentation/networking/netif-msg.txt
> This document was updated last time in 2006 and I doubt that it is
> relevant in 2016. You have dynamic debug prints infrastructure for it,
> use it.

Joe answer for that.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web