Thanks Danny, That means DPDK ports have to have dedicated control path other than KNI.
I originally got confused by the statement at http://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html: "...Allows management of DPDK ports using standard Linux net tools such as ethtool, ifconfig and tcpdump." Thanks, Tim At 2015-02-25 13:05:08, "Zhou, Danny" <danny.zhou at intel.com> wrote: >You can do it but it will not sync with DPDK. In current KNI implementation, >the devices' >I/O address spaces are mapped to both userspace DPDK and kenrelspace KNI, so >one >can control the NIC device independently(using ethtool for KNI and ethdev APIs >for DPDK) >without synchronization. > >In theory, KNI should route all device control request from ethtool to DPDK. >But unfortunately, >a short path is adopted at the moment due to DPDK reused lots of legacy kernel >codes with BSD license. > >> -----Original Message----- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tim Deng >> Sent: Wednesday, February 25, 2015 9:57 AM >> To: dev at dpdk.org >> Subject: [dpdk-dev] Manage DPDK port capability via KNI >> >> Hi, >> >> >> I am wondering how could we manage a DPDK port offload capabilities, >> e.g. if we want to disable TSO capability on a DPDK port, is it feasible >> that we use ethtool to configure a KNI then the config will be sync to a >> DPDK port? >> >> >> Thanks, >> Tim
