Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On 01.07.2010 19:12, Casey Leedom wrote: | From: Stefan Assmann sassm...@redhat.com | Date: Wednesday, June 30, 2010 11:37 pm | | You're correct, the problem shouldn't occur with cxgb4vf and therefore | this change shouldn't be necessary. However we might consider a | consistent naming scheme for VFs in all drivers. But I don't have a | strong opinion about this, either way would be fine by me. Sorry, I hadn't meant to imply any criticism of your naming proposal. I was just trying to clarify when/where such a scheme might be necessary. Sure, that's the reason why we're discussing this here. On the naming proposal itself, it strikes me that the most common use of PCI-E SR-IOV Virtual Functions will be to export them to KVM Virtual Machines via PCI Pass Through. So there shouldn't be any naming conflict there, right? Or is it the same scenario you described before: that the VF NIC device might be found before the normal eth0, etc. withing the Virtual Machine? I haven't had a scenario were passing multiple VF NICs to the guest was necessary. In theory it might happen there as well, if you have multiple NICs (with persistent and random MACs) in the guest. But usually you just have a single VF inside the guest and then you're fine. The scenario that I'm targeting is on the host side mostly. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] Need your valuable feedback on changes done in Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN 802.1Q tag.
Hi,
I am using Linux 2.6.9-55.ELsmp and Intel(R) PRO/1000 Network e1000 driver
(version 7.2.12). I find, this driver does not pass VLAN 802.1Q tags to pcap
library, hence wireshark (Version 1.2.4 or version: 0.99.5) or tcpdump can’t
see them. Then I reviewed at Intel’s e1000 driver (version: 7.6.12) source code
and VLAN 802.1Q kernel module source code, pinpointed the root cause and its
appropriate solution. Afterward I changed the driver source code (on the top
of e1000 driver version: 7.6.12 and rebuild the e1000.ko used the same. Using
this patch, now the VLAN 802.1Q tag visible to sniffers (i.e., wireshark,
tcpdump). I have written Root Cause Analysis, modification done in driver
source code and test results as stated below. Please have a look into the same
and give your valuable feedback.
Root Cause:
Wireshark supports capturing VLAN packet but it depends upon the NIC and
driver. In ATCA GPU (NetHawk Image Version: 1.0.4r1), wireshark does not
capture the VLAN packets because of driver not due to wireshark. I mean, the
e1000 driver strips off the VLAN 802.1Q tag during reception before wireshark
captures them.
Many hours of googling, looking at the e1000 driver code and VLAN 802.1Q code,
has led us to believe that VLAN hardware acceleration is stripping the VLAN tag
from the Ethernet frame, so we can't actually see the VLAN ID. VLAN hardware
acceleration was the issue; as of kernel 2.6.9-55.ELsmp, thus we can’t see the
VLAN tags on real physical interface (i.e., eth0). It shows all the traffic,
but the packets are all untagged.
Note: The VLAN acceleration works (with e1000 driver) by enabling HW header
striping and using the VLAN ID for an immediate lookup in the VLAN devices
configured on that device.
Solution:
We need to make a patch which disables all HW vlan acceleration features (rx,
tx,
filter) for netdevice. The net_device structure (defined in
include/linux/netdevice.h), which is filled-in by a net driver at
initialization time, includes a field called features. The features field
inside the structure net_device reports the card's capabilities. As of e1000
driver (version 7.6.12), by setting NETIF_F_HW_VLAN_TX, NETIF_F_HW_VLAN_RX, and
NETIF_F_HW_VLAN_FILTER bits in features field, the driver informs the
networking stack of it's capabilities for all HW vlan acceleration features. We
need to unset those bits in bitmap of flags used to store device capabilities.
This does the followings
a) It disables all HW vlan acceleration features.
b) It makes e1000 driver to not strip off the VLAN header.
c) Then, the packets will be received by the networking stack with the
vlan header intact.
d) It makes automatically VLAN 802.1Q tag visible to sniffers by sniffing
on the physical device.
Note: We can find the list of NETIF_F_XXX features, along with some comments,
inside the net_device data structure definition.
Modified Source Code i.e., drivers/net/e1000/e1000_main.c
Convention Used : The blue colored statements signifies the modification
static int __devinit e1000_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- ;
- ;
netdev-features = NETIF_F_SG |
NETIF_F_HW_CSUM; /* |
NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;*/
- ;
- ;
}
Results:
In two Linux box created the VLAN device (i.e. eth5.7) associated with eth5
with the vconfig command and added the IP address thru IP utility. Then did
pinging from both the ends and captured the packets (by selecting eth5
interface) and wireshark could able to capture these packets and displays all
the fields as per 802.1Q specification.
Regards,
ChinmayaD
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] Need your valuable feedback on changes done in Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN 802.1Q tag.
Did you try our latest stand-alone driver available on our Sourceforge site,
http://e1000.sf.net? You are using a very old kernel and driver. Please our
latest driver and get back to us if it works for you.
Cheers,
John
-Original Message-
From: Chinmaya Dwibedy [mailto:ckdwib...@yahoo.com]
Sent: Friday, July 02, 2010 3:54 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Need your valuable feedback on changes done in
Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN
802.1Q tag.
Hi,
I am using Linux 2.6.9-55.ELsmp and Intel(R) PRO/1000 Network e1000
driver (version 7.2.12). I find, this driver does not pass VLAN 802.1Q
tags to pcap library, hence wireshark (Version 1.2.4 or version:
0.99.5) or tcpdump can’t see them. Then I reviewed at Intel’s e1000
driver (version: 7.6.12) source code and VLAN 802.1Q kernel module
source code, pinpointed the root cause and its appropriate solution.
Afterward I changed the driver source code (on the top of e1000 driver
version: 7.6.12 and rebuild the e1000.ko used the same. Using this
patch, now the VLAN 802.1Q tag visible to sniffers (i.e., wireshark,
tcpdump). I have written Root Cause Analysis, modification done in
driver source code and test results as stated below. Please have a look
into the same and give your valuable feedback.
Root Cause:
Wireshark supports capturing VLAN packet but it depends upon the NIC
and driver. In ATCA GPU (NetHawk Image Version: 1.0.4r1), wireshark
does not capture the VLAN packets because of driver not due to
wireshark. I mean, the e1000 driver strips off the VLAN 802.1Q tag
during reception before wireshark captures them.
Many hours of googling, looking at the e1000 driver code and VLAN
802.1Q code, has led us to believe that VLAN hardware acceleration is
stripping the VLAN tag from the Ethernet frame, so we can't actually
see the VLAN ID. VLAN hardware acceleration was the issue; as of kernel
2.6.9-55.ELsmp, thus we can’t see the VLAN tags on real physical
interface (i.e., eth0). It shows all the traffic, but the packets are
all untagged.
Note: The VLAN acceleration works (with e1000 driver) by enabling HW
header striping and using the VLAN ID for an immediate lookup in the
VLAN devices configured on that device.
Solution:
We need to make a patch which disables all HW vlan acceleration
features (rx, tx,
filter) for netdevice. The net_device structure (defined in
include/linux/netdevice.h), which is filled-in by a net driver at
initialization time, includes a field called features. The features
field inside the structure net_device reports the card's capabilities.
As of e1000 driver (version 7.6.12), by setting NETIF_F_HW_VLAN_TX,
NETIF_F_HW_VLAN_RX, and NETIF_F_HW_VLAN_FILTER bits in features field,
the driver informs the networking stack of it's capabilities for all HW
vlan acceleration features. We need to unset those bits in bitmap of
flags used to store device capabilities. This does the followings
a) It disables all HW vlan acceleration features.
b) It makes e1000 driver to not strip off the VLAN header.
c) Then, the packets will be received by the networking stack with
the vlan header intact.
d) It makes automatically VLAN 802.1Q tag visible to sniffers by
sniffing on the physical device.
Note: We can find the list of NETIF_F_XXX features, along with some
comments, inside the net_device data structure definition.
Modified Source Code i.e., drivers/net/e1000/e1000_main.c
Convention Used : The blue colored statements signifies the
modification
static int __devinit e1000_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- ;
- ;
netdev-features = NETIF_F_SG |
NETIF_F_HW_CSUM; /* |
NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;*/
- ;
- ;
}
Results:
In two Linux box created the VLAN device (i.e. eth5.7) associated with
eth5 with the vconfig command and added the IP address thru IP utility.
Then did pinging from both the ends and captured the packets (by
selecting eth5 interface) and wireshark could able to capture these
packets and displays all the fields as per 802.1Q specification.
Regards,
ChinmayaD
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet,
Re: [E1000-devel] [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
On Wed, 30 Jun 2010 13:44:32 +0100 Ben Hutchings wrote:
ethtool_op_set_flags() does not check for unsupported flags, and has
no way of doing so. This means it is not suitable for use as a
default implementation of ethtool_ops::set_flags.
Add a 'supported' parameter specifying the flags that the driver and
hardware support, validate the requested flags against this, and
change all current callers to pass this parameter.
Change some other trivial implementations of ethtool_ops::set_flags to
call ethtool_op_set_flags().
Signed-off-by: Ben Hutchings bhutchi...@solarflare.com
Reviewed-by: Stanislaw Gruszka sgrus...@redhat.com
Acked-by: Jeff Garzik jgar...@redhat.com
---
drivers/net/cxgb4/cxgb4_main.c|9 +
drivers/net/enic/enic_main.c |1 -
drivers/net/ixgbe/ixgbe_ethtool.c |5 -
drivers/net/mv643xx_eth.c |7 ++-
drivers/net/myri10ge/myri10ge.c | 10 +++---
drivers/net/niu.c |9 +
drivers/net/sfc/ethtool.c |5 +
drivers/net/sky2.c| 16 ++--
include/linux/ethtool.h |2 +-
net/core/ethtool.c| 28 +---
10 files changed, 32 insertions(+), 60 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 2c8af09..084ddb3 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -457,7 +457,7 @@ int ethtool_op_set_tso(struct net_device *dev, u32 data);
u32 ethtool_op_get_ufo(struct net_device *dev);
int ethtool_op_set_ufo(struct net_device *dev, u32 data);
u32 ethtool_op_get_flags(struct net_device *dev);
-int ethtool_op_set_flags(struct net_device *dev, u32 data);
+int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported);
That one-line change is missing from linux-next-20100702, causing:
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c:157: warning: initialization from
incompatible pointer type
but the change (below) to net/core/ethtool.c is merged.
I don't quite see how this happened...
void ethtool_ntuple_flush(struct net_device *dev);
/**
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a0f4964..5d42fae 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -144,31 +144,13 @@ u32 ethtool_op_get_flags(struct net_device *dev)
}
EXPORT_SYMBOL(ethtool_op_get_flags);
-int ethtool_op_set_flags(struct net_device *dev, u32 data)
+int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
{
- const struct ethtool_ops *ops = dev-ethtool_ops;
- unsigned long features = dev-features;
-
- if (data ETH_FLAG_LRO)
- features |= NETIF_F_LRO;
- else
- features = ~NETIF_F_LRO;
-
- if (data ETH_FLAG_NTUPLE) {
- if (!ops-set_rx_ntuple)
- return -EOPNOTSUPP;
- features |= NETIF_F_NTUPLE;
- } else {
- /* safe to clear regardless */
- features = ~NETIF_F_NTUPLE;
- }
-
- if (data ETH_FLAG_RXHASH)
- features |= NETIF_F_RXHASH;
- else
- features = ~NETIF_F_RXHASH;
+ if (data ~supported)
+ return -EINVAL;
- dev-features = features;
+ dev-features = ((dev-features ~flags_dup_features) |
+ (data flags_dup_features));
return 0;
}
EXPORT_SYMBOL(ethtool_op_set_flags);
--
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel#174; Ethernet, visit
http://communities.intel.com/community/wired
Re: [E1000-devel] Need your valuable feedback on changes done in Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN 802.1Q tag.
Hi John,
I downloaded ixgbe-2.0.84.9 driver from http://e1000.sf.net. Do you say that
this driver does not strip off the VLAN 802.1Q tag during reception before
wireshark captures them using kernel 2.6.9-55.ELsmp? Please clarify and confirm.
Regards,
ChinmayaD
--- On Fri, 7/2/10, Ronciak, John john.ronc...@intel.com wrote:
From: Ronciak, John john.ronc...@intel.com
Subject: RE: [E1000-devel] Need your valuable feedback on changes done in
Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN 802.1Q
tag.
To: Chinmaya Dwibedy ckdwib...@yahoo.com,
e1000-devel@lists.sourceforge.net e1000-devel@lists.sourceforge.net
Date: Friday, July 2, 2010, 9:21 PM
Did you try our latest stand-alone driver available on our Sourceforge site,
http://e1000.sf.net? You are using a very old kernel and driver. Please our
latest driver and get back to us if it works for you.
Cheers,
John
-Original Message-
From: Chinmaya Dwibedy [mailto:ckdwib...@yahoo.com]
Sent: Friday, July 02, 2010 3:54 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] Need your valuable feedback on changes done in
Intel(R) PRO/1000 Network e1000 driver (version 7.2.12) to capture VLAN
802.1Q tag.
Hi,
I am using Linux 2.6.9-55.ELsmp and Intel(R) PRO/1000 Network e1000
driver (version 7.2.12). I find, this driver does not pass VLAN 802.1Q
tags to pcap library, hence wireshark (Version 1.2.4 or version:
0.99.5) or tcpdump can’t see them. Then I reviewed at Intel’s e1000
driver (version: 7.6.12) source code and VLAN 802.1Q kernel module
source code, pinpointed the root cause and its appropriate solution.
Afterward I changed the driver source code (on the top of e1000 driver
version: 7.6.12 and rebuild the e1000.ko used the same. Using this
patch, now the VLAN 802.1Q tag visible to sniffers (i.e., wireshark,
tcpdump). I have written Root Cause Analysis, modification done in
driver source code and test results as stated below. Please have a look
into the same and give your valuable feedback.
Root Cause:
Wireshark supports capturing VLAN packet but it depends upon the NIC
and driver. In ATCA GPU (NetHawk Image Version: 1.0.4r1), wireshark
does not capture the VLAN packets because of driver not due to
wireshark. I mean, the e1000 driver strips off the VLAN 802.1Q tag
during reception before wireshark captures them.
Many hours of googling, looking at the e1000 driver code and VLAN
802.1Q code, has led us to believe that VLAN hardware acceleration is
stripping the VLAN tag from the Ethernet frame, so we can't actually
see the VLAN ID. VLAN hardware acceleration was the issue; as of kernel
2.6.9-55.ELsmp, thus we can’t see the VLAN tags on real physical
interface (i.e., eth0). It shows all the traffic, but the packets are
all untagged.
Note: The VLAN acceleration works (with e1000 driver) by enabling HW
header striping and using the VLAN ID for an immediate lookup in the
VLAN devices configured on that device.
Solution:
We need to make a patch which disables all HW vlan acceleration
features (rx, tx,
filter) for netdevice. The net_device structure (defined in
include/linux/netdevice.h), which is filled-in by a net driver at
initialization time, includes a field called features. The features
field inside the structure net_device reports the card's capabilities.
As of e1000 driver (version 7.6.12), by setting NETIF_F_HW_VLAN_TX,
NETIF_F_HW_VLAN_RX, and NETIF_F_HW_VLAN_FILTER bits in features field,
the driver informs the networking stack of it's capabilities for all HW
vlan acceleration features. We need to unset those bits in bitmap of
flags used to store device capabilities. This does the followings
a) It disables all HW vlan acceleration features.
b) It makes e1000 driver to not strip off the VLAN header.
c) Then, the packets will be received by the networking stack with
the vlan header intact.
d) It makes automatically VLAN 802.1Q tag visible to sniffers by
sniffing on the physical device.
Note: We can find the list of NETIF_F_XXX features, along with some
comments, inside the net_device data structure definition.
Modified Source Code i.e., drivers/net/e1000/e1000_main.c
Convention Used : The blue colored statements signifies the
modification
static int __devinit e1000_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- ;
- ;
netdev-features = NETIF_F_SG |
NETIF_F_HW_CSUM; /* |
NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;*/
- ;
- ;
}
Results:
In two Linux box created the VLAN device (i.e. eth5.7) associated with
eth5 with the vconfig command and added the IP address thru
Re: [E1000-devel] [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: Randy Dunlap randy.dun...@oracle.com Date: Fri, 2 Jul 2010 09:55:14 -0700 On Wed, 30 Jun 2010 13:44:32 +0100 Ben Hutchings wrote: @@ -457,7 +457,7 @@ int ethtool_op_set_tso(struct net_device *dev, u32 data); u32 ethtool_op_get_ufo(struct net_device *dev); int ethtool_op_set_ufo(struct net_device *dev, u32 data); u32 ethtool_op_get_flags(struct net_device *dev); -int ethtool_op_set_flags(struct net_device *dev, u32 data); +int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported); That one-line change is missing from linux-next-20100702, causing: drivers/infiniband/ulp/ipoib/ipoib_ethtool.c:157: warning: initialization from incompatible pointer type Strange, it's in net-next-2.6 for sure: da...@sunset:~/src/GIT/net-next-2.6$ egrep ethtool_op_set_flags include/linux/ethtool.h int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported); -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
