[dpdk-dev] kni: error building with kernel < 3.3 and ether_addr_equal backport

[Patrick McGleenon]

Here is a patch to building DPDK 1.6 on RHEL 6 kernels.   It's similar to the 
issue below.   The kernel version check really only applies to vanilla kernels 
- for commercial distributions it's common for features from later kernels to 
be backported.   Should we be using autoconf or something to check if the code 
is present instead of the kernel version check?

http://www.dpdk.org/browse/dpdk/commit/?id=caa3d413086205f3bff0fa4753edb7dfbfc1f633

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index 6933626..33bb858 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -9275,7 +9275,7 @@ int igb_del_mac_filter(struct igb_adapter *adapter, u8* 
addr, u16 queue)
if (is_zero_ether_addr(addr))
return 0;
for (i = 0; i < hw->mac.rar_entry_count; i++) {
-   if (ether_addr_equal(addr, adapter->mac_table[i].addr) &&
+   if (kni_ether_addr_equal(addr, adapter->mac_table[i].addr) &&
adapter->mac_table[i].queue == queue) {
adapter->mac_table[i].state = IGB_MAC_STATE_MODIFIED;
memset(adapter->mac_table[i].addr, 0, ETH_ALEN);
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index a404c9f..f6f6635 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3528,11 +3528,12 @@ extern void _kc_skb_add_rx_frag(struct sk_buff *, int, 
struct page *,
 /*/
 #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,5,0) )
 #define skb_tx_timestamp(skb) do {} while (0)
-static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
+static inline bool kni_ether_addr_equal(const u8 *addr1, const u8 *addr2)
 {
return !compare_ether_addr(addr1, addr2);
 }
 #else
+typedef ether_addr_equal kni_ether_addr_equal;
 #define HAVE_FDB_OPS
 #define HAVE_ETHTOOL_GET_TS_INFO
 #endif /* < 3.5.0 */
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c 
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
index cb56906..dea2192 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
@@ -525,7 +525,7 @@ int ixgbe_del_mac_filter(struct ixgbe_adapter *adapter, u8* 
addr, u16 queue)
if (is_zero_ether_addr(addr))
return 0;
for (i = 0; i < hw->mac.num_rar_entries; i++) {
-   if (ether_addr_equal(addr, adapter->mac_table[i].addr) &&
+   if (kni_ether_addr_equal(addr, adapter->mac_table[i].addr) &&
adapter->mac_table[i].queue == queue) {
adapter->mac_table[i].state |= IXGBE_MAC_STATE_MODIFIED;
adapter->mac_table[i].state &= ~IXGBE_MAC_STATE_IN_USE;
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h 
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
index 3fb6b14..45f6c4c 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
@@ -3107,11 +3107,12 @@ typedef netdev_features_t kni_netdev_features_t;

 /*/
 #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,5,0) )
-static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
+static inline bool kni_ether_addr_equal(const u8 *addr1, const u8 *addr2)
 {
return !compare_ether_addr(addr1, addr2);
 }
 #else
+typedef ether_addr_equal kni_ether_addr_equal;
 #define HAVE_FDB_OPS
 #endif /* < 3.5.0 */

[dpdk-dev] kni: error building with kernel < 3.3 and ether_addr_equal backport

[Patrick McGleenon]

Hello David

Good point - I only compiled it on RHEL 6.4.   If you remove the typedefs it 
should compile on the later kernel

thanks
Patrick

[dpdk-dev] Question on using SR-IOV with dpdk apps

[Patrick McGleenon]

I had this when the PF was down, bringing it back with "ifup" fixed it.   
Assuming you've already checked it's not the issue described in the FAQ :)
With a RHEL 6.5 host the ixgbe driver prints the VF MAC addresses in 
/var/log/syslog when the VFs are enabled

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Anjali Kulkarni
Sent: 04 August 2014 21:26
To: Anjali Kulkarni; Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] Question on using SR-IOV with dpdk apps

The 4 devices in qs are at 04:10.0, 04:10.1, 04:10.2, 04:10.3

Anjali

On 8/4/14 1:24 PM, "Anjali Kulkarni"  wrote:

>It seems to have detected all 4. But I do see a MAC address not valid:
>:
>:
>(scrolled up)
>
>EAL: PCI device :04:10.1 on NUMA socket 0  ?
>EAL:   probe driver: 8086:10ed rte_ixgbevf_pmd ?
>EAL:   PCI memory mapped at 0x7fd39743e000 ?
>EAL:   PCI memory mapped at 0x7fd39743a000 ?
>PMD:The MAC address is not valid.  ?
> The most likely cause of this error is that the VM host?
> has not assigned a valid MAC address to this VF device.?
> Please consult the DPDK Release Notes (FAQ section) for?
> a possible solution to this problem.   ?
>EAL: PCI device :04:10.2 on NUMA socket 0  ?
>EAL:   probe driver: 8086:10ed rte_ixgbevf_pmd ?
>EAL:   PCI memory mapped at 0x7fd397436000 ?
>EAL:   PCI memory mapped at 0x7fd397432000 ?
>EAL: PCI device :04:10.3 on NUMA socket 0  ?
>EAL:   probe driver: 8086:10ed rte_ixgbevf_pmd ?
>EAL:   PCI memory mapped at 0x7fd39742e000 ?
>EAL:   PCI memory mapped at 0x7fd39742a000 ?
>PMD:The MAC address is not valid.  ?
> The most likely cause of this error is that the VM host?
> has not assigned a valid MAC address to this VF device.?
> Please consult the DPDK Release Notes (FAQ section) for?
> a possible solution to this problem.
>
>