Hi, Just thought it would be useful to add ethtool support for poll mode driver, so we could control/check various hardware features on demand. Do you guys have any plan for this? Thanks, -hs
Please refer KNI - the support for ethtool e.g., lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of HS Sent: Monday, June 02, 2014 9:32 AM To: dev@dpdk.org Subject: [dpdk-dev] Ethtool support in DPDK pmd Hi, Just thought it would be useful to add ethtool support for poll mode driver, so we could control/check various hardware features on demand. Do you guys have any plan for this? Thanks, -hs
Thanks for your reply.
Sure KNI can offer ethtool interface. But suppose I am already running a
DPDK application on a physical port, but at the same time I want to control
the port with ethtool like interface. How could I do that?
-hs
On Mon, Jun 2, 2014 at 12:37 PM, Jayakumar, Muthurajan <
muthurajan.jayakumar@intel.com> wrote:
> Please refer KNI - the support for ethtool e.g.,
> lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of HS
> Sent: Monday, June 02, 2014 9:32 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Ethtool support in DPDK pmd
>
> Hi,
>
> Just thought it would be useful to add ethtool support for poll mode
> driver, so we could control/check various hardware features on demand. Do
> you guys have any plan for this?
>
> Thanks,
> -hs
>
* HS (hyunseok@ieee.org) wrote:
> Thanks for your reply.
>
> Sure KNI can offer ethtool interface. But suppose I am already running a
> DPDK application on a physical port, but at the same time I want to control
> the port with ethtool like interface. How could I do that?
HS, I might be missing something there, but with the current model of
usermode device drivers I don't think this is simple.
If drivers stayed in kernel and kernel drivers exposed a mechansim for
registering application dma buffers for dpdk apps, then ethtool would
simply work as-is.
thanks,
-chris
On 02/06/2014 22:37, Chris Wright wrote:
> If drivers stayed in kernel and kernel drivers exposed a mechansim for
> registering application dma buffers for dpdk apps, then ethtool would
> simply work as-is.
Yes, that's the right way to go. Currently, the kernel does not provide
a generic framework for that and I am not aware of any projects in order
to define it. Could it be something to discuss on netdev@?
So, as a workaround, some proprietary solutions get implemented in order
to get ethtool running with any DPDK PMD.
Best regards,
Vincent
On Mon, 02 Jun 2014 23:35:12 +0200
Vincent JARDIN <vincent.jardin@6wind.com> wrote:
> On 02/06/2014 22:37, Chris Wright wrote:
> > If drivers stayed in kernel and kernel drivers exposed a mechansim for
> > registering application dma buffers for dpdk apps, then ethtool would
> > simply work as-is.
>
> Yes, that's the right way to go. Currently, the kernel does not provide
> a generic framework for that and I am not aware of any projects in order
> to define it. Could it be something to discuss on netdev@?
>
> So, as a workaround, some proprietary solutions get implemented in order
> to get ethtool running with any DPDK PMD.
>
> Best regards,
> Vincent
Ethtool has a number of problems. You can implement for KNI or TUN type
devices, but it really doesn't make sense for a generic type driver.
Also, it tends to get used for device specific things.