Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues
Thanks for your reply. I issue is, that I do have different source IP and destination IP ( different VLANs for client and PPPoE server ) on layer 2. According to data sheet, this falls under IPv4 rule ( page 237 of DS ). This rule should parse L2 header and hash it. Configuration is the following ( sorry for not posting it before ): Client has VLAN 2 and VLAN 3. IPs with mask /30. Server has VLAN 2 and VLAN 3 and 2 PPPoE servers running on each of them. IPs with mask /30. IP addressing inside PPPoE doesn't matter, since it's Layer 4. RSS hash should be different for each of the VLANs, isn't it? BTW I tried the same without VLANs, using different MACs ( macvlan functionality ) and different IPs. Issue is the same. That's why I think it's a bug in hashing function or in modification of MRQC register from driver side. Also I've tried to modify driver and leave in MRQC only IPV4 rule for hashing. Didn't help either. Regarding VMDq: in previous emails I've reported that it's not starting for me, so I do not know how to proceed. And the other question is: how to use them in production? In production I will have 2-3 VLANs, with lot of unknown ( to NIC ) MAC addresses. How to balance the traffic in this case? Hopefully you will be able to help in this. Thank you. - Original Message - From: Todd Fujinaka todd.fujin...@intel.com To: Jack Spinov spi...@timegroup.ae, Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 8:25:31 PM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues RSS hashing is pretty simple. Do you have the same source and destination address and port? If so, you get one hash. I'm not sure what your packets look like, I've been told by those who know more about PPoE that you'll need to use VMDq. I know there are other ways for traffic to be routed to the default queue (0) but I think in this case VMDq is the way to go. I am guessing that VMDq isn't trivial and I'll have to look into this some more for you. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Thursday, May 15, 2014 5:46 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues According to driver source code functions are executed in order ( I skipped IPv6 ): IPv4, IPv4_TCP and if UDP flow hashing is enabled - IPv4_UDP. If yes, then I do not understand, why hash function returns 0 ( i.e. assigns packets to 0 queue ) for PPPoE packets. Looks like a bug to me. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 3:11:03 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues And one more thing. According to Data Sheet, RSS can properly parse tunneled packets, treating them as IP packets. In this case hash is built by SourceAddress and DestinationAddress. However, it's stated, that in case RSS function failed to parse packet - function returns zero. Without ntuple and Flow Director ( do not work for tunneled packets ), this means, that packets will always go to queue 0, which is my case. So the question is: is there a way to find out what functions RSS uses to parse IP packets, i.e. value of MRQC register? And modify it. It seems to me, that needed function for parsing is just not included into check. Adding it will render RSS index assigned and packets will be properly distributed among queues. Unicorns and rainbows. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 12:37:47 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply. I'll try that for synthetic tests. But it's unclear what to do, in case I will not have VLANs or will have just few in production? VMDq without virtual environment looks like workaround to me. Let's say server is BRAS with PPPoE server terminating client sessions. Without PPPoE - everything is working as it should. Once PPPoE in effect - everything gets to queue 0. How can I configure VFs in this case? - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae, e1000-devel@lists.sourceforge.net Sent: Wednesday, May 14, 2014 9:05:27 PM Subject: RE: [E1000-devel] ixgbe:
Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues
Thanks for your reply, Donald. Looks like you're right. Src IP offset starts at 23 bit and Dst IP at 27. Instead of 12 and 16. Just a rhetoric question: why not to have hash function on MAC? And not rhetoric: how to balance damn PPPoE traffic? BTW I didn't had any issue balancing such traffic on 82579. Everything worked perfectly. - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae Cc: e1000-devel@lists.sourceforge.net Sent: Friday, May 16, 2014 12:00:10 AM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues I might be misunderstanding what you're trying to do here, but the reason you're going to queue 0 is that you are tunneling over PPPoE. Because of this all of the offsets that the HW expects are no longer correct so it can't hash on the IPv4, IPv4_TCP and if UDP fields RSS needs. Thanks, -Don Skidmore donald.c.skidm...@intel.com -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Thursday, May 15, 2014 5:46 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues According to driver source code functions are executed in order ( I skipped IPv6 ): IPv4, IPv4_TCP and if UDP flow hashing is enabled - IPv4_UDP. If yes, then I do not understand, why hash function returns 0 ( i.e. assigns packets to 0 queue ) for PPPoE packets. Looks like a bug to me. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 3:11:03 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues And one more thing. According to Data Sheet, RSS can properly parse tunneled packets, treating them as IP packets. In this case hash is built by SourceAddress and DestinationAddress. However, it's stated, that in case RSS function failed to parse packet - function returns zero. Without ntuple and Flow Director ( do not work for tunneled packets ), this means, that packets will always go to queue 0, which is my case. So the question is: is there a way to find out what functions RSS uses to parse IP packets, i.e. value of MRQC register? And modify it. It seems to me, that needed function for parsing is just not included into check. Adding it will render RSS index assigned and packets will be properly distributed among queues. Unicorns and rainbows. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 12:37:47 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS tomultiple queues Thanks for your reply. I'll try that for synthetic tests. But it's unclear what to do, in case I will not have VLANs or will have just few in production? VMDq without virtual environment looks like workaround to me. Let's say server is BRAS with PPPoE server terminating client sessions. Without PPPoE - everything is working as it should. Once PPPoE in effect - everything gets to queue 0. How can I configure VFs in this case? - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae, e1000-devel@lists.sourceforge.net Sent: Wednesday, May 14, 2014 9:05:27 PM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Maybe try VMDq which could sort by L2 (MAC address and VLAN). Thanks, -Don Skidmore donald.c.skidm...@intel.com -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Tuesday, May 13, 2014 7:39 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Hello, everyone. Have spent a lot of time trying to balance traffic into multiple RSS queues, but traffic falls into same queue all the time. I've read all the documents, threads I could find, but still cannot find a way to solve my problem. My configuration: 3 servers with 82599 adapters. Connected like this: Packet generator ( PG )--- 10G --- Packet router ( PR )--- 10G --- Packet dumper ( PD ) PG connects to PR via PPPoE and generates packets directed to Packed dumper ( PG ).
Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues
Sorry, givven offsets in different dimensions. PPPoE src IP starts at 184 bit, dst IP starts at 216, instead of 96 and 128 respectively. Just to correct myself. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Friday, May 16, 2014 11:14:36 AM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply, Donald. Looks like you're right. Src IP offset starts at 23 bit and Dst IP at 27. Instead of 12 and 16. Just a rhetoric question: why not to have hash function on MAC? And not rhetoric: how to balance damn PPPoE traffic? BTW I didn't had any issue balancing such traffic on 82579. Everything worked perfectly. - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae Cc: e1000-devel@lists.sourceforge.net Sent: Friday, May 16, 2014 12:00:10 AM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues I might be misunderstanding what you're trying to do here, but the reason you're going to queue 0 is that you are tunneling over PPPoE. Because of this all of the offsets that the HW expects are no longer correct so it can't hash on the IPv4, IPv4_TCP and if UDP fields RSS needs. Thanks, -Don Skidmore donald.c.skidm...@intel.com -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Thursday, May 15, 2014 5:46 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues According to driver source code functions are executed in order ( I skipped IPv6 ): IPv4, IPv4_TCP and if UDP flow hashing is enabled - IPv4_UDP. If yes, then I do not understand, why hash function returns 0 ( i.e. assigns packets to 0 queue ) for PPPoE packets. Looks like a bug to me. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 3:11:03 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues And one more thing. According to Data Sheet, RSS can properly parse tunneled packets, treating them as IP packets. In this case hash is built by SourceAddress and DestinationAddress. However, it's stated, that in case RSS function failed to parse packet - function returns zero. Without ntuple and Flow Director ( do not work for tunneled packets ), this means, that packets will always go to queue 0, which is my case. So the question is: is there a way to find out what functions RSS uses to parse IP packets, i.e. value of MRQC register? And modify it. It seems to me, that needed function for parsing is just not included into check. Adding it will render RSS index assigned and packets will be properly distributed among queues. Unicorns and rainbows. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 12:37:47 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply. I'll try that for synthetic tests. But it's unclear what to do, in case I will not have VLANs or will have just few in production? VMDq without virtual environment looks like workaround to me. Let's say server is BRAS with PPPoE server terminating client sessions. Without PPPoE - everything is working as it should. Once PPPoE in effect - everything gets to queue 0. How can I configure VFs in this case? - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae, e1000-devel@lists.sourceforge.net Sent: Wednesday, May 14, 2014 9:05:27 PM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS tomultiple queues Maybe try VMDq which could sort by L2 (MAC address and VLAN). Thanks, -Don Skidmore donald.c.skidm...@intel.com -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Tuesday, May 13, 2014 7:39 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Hello, everyone.
[E1000-devel] [PATCH net-next] i40evf: Use is_multicast_ether_addr helper
Use the is_multicast_ether_addr helper function from linux/etherdevice.h
instead of open coding the multicast address check.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 6edd581..8b5c734 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -843,7 +843,7 @@ static void i40evf_set_rx_mode(struct net_device *netdev)
list_for_each_entry_safe(f, ftmp, adapter-mac_filter_list, list) {
bool found = false;
- if (f-macaddr[0] 0x01) {
+ if (is_multicast_ether_addr(f-macaddr)) {
netdev_for_each_mc_addr(mca, netdev) {
if (ether_addr_equal(mca-addr, f-macaddr)) {
found = true;
--
1.7.9.5
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
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] [PATCH net-next] e1000: Use is_broadcast_ether_addr/is_multicast_ether_addr helpers
Use the is_broadcast_ether_addr/is_multicast_ether_addr helper functions from linux/etherdevice.h instead of open coding them. Signed-off-by: Tobias Klauser tklau...@distanz.ch --- drivers/net/ethernet/intel/e1000/e1000_hw.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c b/drivers/net/ethernet/intel/e1000/e1000_hw.c index c1d3fdb..e9b07cc 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_hw.c +++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c @@ -4877,10 +4877,10 @@ void e1000_tbi_adjust_stats(struct e1000_hw *hw, struct e1000_hw_stats *stats, * since the test for a multicast frame will test positive on * a broadcast frame. */ - if ((mac_addr[0] == (u8) 0xff) (mac_addr[1] == (u8) 0xff)) + if (is_broadcast_ether_addr(mac_addr)) /* Broadcast packet */ stats-bprc++; - else if (*mac_addr 0x01) + else if (is_multicast_ether_addr(mac_addr)) /* Multicast packet */ stats-mprc++; -- 1.7.9.5 -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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] 82579 Transmit hang with C200 and ME
Hi Dave, Thanks for the reply. I meant to say the E1000e. I started with version 2.5.4 and merged in anything new I found in version 3.04. Matt Edwards -Original Message- From: Ertman, DavidX M [mailto:davidx.m.ert...@intel.com] Sent: Thursday, May 15, 2014 5:45 PM To: Matt Edwards; e1000-devel@lists.sourceforge.net Subject: RE: 82579 Transmit hang with C200 and ME -Original Message- From: Matt Edwards [mailto:matt.edwa...@intervalzero.com] Sent: Wednesday, May 07, 2014 10:04 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] 82579 Transmit hang with C200 and ME Hello, I have modified the current E1000 for a small embedded system. The driver works well on systems that do not have Intel ME. On systems that have Intel ME the transmit hangs. BTW the only systems I have tested with ME are C200 PCH boards. The problem could also be the result of differences between the C200 and C202. On transmit I have verified that transmit descriptor head and tail pointer registers are correct after the driver loads up the DMA buffers but the MAC never sends the frames and never updates the head, and never sets the DD bit. This code works with other NIC's and on other 82579 NIC's. Receive DMA works fine. I've had transmit hangs when the PHY throws data away, but when that happens the MAC updates the descriptors as thought the packets were transmitted. Is there something at the system level that must be running with Intel ME. I've gone the E1000 driver to find all ME specific code and I think I have included it. Any help is very much appreciated, Best Regards, Matt Good afternoon Matt, You started with the e1000 driver? Why not the e1000e driver? There are quite a few workarounds for 82579 in the e1000e driver that do not exist in e1000. Dave Ertman -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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] ixgbe: how to balance PPPoE traffic via RSS to multiple queues
-Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Friday, May 16, 2014 12:15 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply, Donald. Looks like you're right. Src IP offset starts at 23 bit and Dst IP at 27. Instead of 12 and 16. Just a rhetoric question: why not to have hash function on MAC? And not rhetoric: how to balance damn PPPoE traffic? Have you looked into RPS: https://www.kernel.org/doc/Documentation/networking/scaling.txt Thanks, Emil -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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] ixgbe: how to balance PPPoE traffic via RSS to multiple queues
So the offsets are off because you are tunneling and it looks like you're coming from the same port and address. To answer some of your other questions: RSS is defined by Microsoft and you'll have to take that up with them. You've now been given two options to balance your traffic: vmdq (not trivial) and RPS. If you're not having trouble with the 82579 you may already be using something to spread the traffic as e1000e only has one queue and so does the 82579. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Friday, May 16, 2014 12:22 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Sorry, givven offsets in different dimensions. PPPoE src IP starts at 184 bit, dst IP starts at 216, instead of 96 and 128 respectively. Just to correct myself. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Friday, May 16, 2014 11:14:36 AM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply, Donald. Looks like you're right. Src IP offset starts at 23 bit and Dst IP at 27. Instead of 12 and 16. Just a rhetoric question: why not to have hash function on MAC? And not rhetoric: how to balance damn PPPoE traffic? BTW I didn't had any issue balancing such traffic on 82579. Everything worked perfectly. - Original Message - From: Donald C Skidmore donald.c.skidm...@intel.com To: Jack Spinov spi...@timegroup.ae Cc: e1000-devel@lists.sourceforge.net Sent: Friday, May 16, 2014 12:00:10 AM Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues I might be misunderstanding what you're trying to do here, but the reason you're going to queue 0 is that you are tunneling over PPPoE. Because of this all of the offsets that the HW expects are no longer correct so it can't hash on the IPv4, IPv4_TCP and if UDP fields RSS needs. Thanks, -Don Skidmore donald.c.skidm...@intel.com -Original Message- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Thursday, May 15, 2014 5:46 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues According to driver source code functions are executed in order ( I skipped IPv6 ): IPv4, IPv4_TCP and if UDP flow hashing is enabled - IPv4_UDP. If yes, then I do not understand, why hash function returns 0 ( i.e. assigns packets to 0 queue ) for PPPoE packets. Looks like a bug to me. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 3:11:03 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues And one more thing. According to Data Sheet, RSS can properly parse tunneled packets, treating them as IP packets. In this case hash is built by SourceAddress and DestinationAddress. However, it's stated, that in case RSS function failed to parse packet - function returns zero. Without ntuple and Flow Director ( do not work for tunneled packets ), this means, that packets will always go to queue 0, which is my case. So the question is: is there a way to find out what functions RSS uses to parse IP packets, i.e. value of MRQC register? And modify it. It seems to me, that needed function for parsing is just not included into check. Adding it will render RSS index assigned and packets will be properly distributed among queues. Unicorns and rainbows. - Original Message - From: Jack Spinov spi...@timegroup.ae To: Donald C Skidmore donald.c.skidm...@intel.com Cc: e1000-devel@lists.sourceforge.net Sent: Thursday, May 15, 2014 12:37:47 PM Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues Thanks for your reply. I'll try that for synthetic tests. But it's unclear what to do, in case I will not have VLANs or will have just few in production? VMDq without virtual environment looks like workaround to me. Let's say server is BRAS with PPPoE server terminating client sessions. Without PPPoE - everything is working as it should. Once PPPoE in effect - everything gets to queue 0. How can I configure VFs in this case? -
Re: [E1000-devel] [PATCH net-next] e1000: Use is_broadcast_ether_addr/is_multicast_ether_addr helpers
From: Tobias Klauser tklau...@distanz.ch Date: Fri, 16 May 2014 10:00:38 +0200 Use the is_broadcast_ether_addr/is_multicast_ether_addr helper functions from linux/etherdevice.h instead of open coding them. Signed-off-by: Tobias Klauser tklau...@distanz.ch I'll let Jeff Kirsher take this via his tree. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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] [PATCH net-next] i40evf: Use is_multicast_ether_addr helper
From: Tobias Klauser tklau...@distanz.ch Date: Fri, 16 May 2014 10:00:34 +0200 Use the is_multicast_ether_addr helper function from linux/etherdevice.h instead of open coding the multicast address check. Signed-off-by: Tobias Klauser tklau...@distanz.ch Likewise, I'll let Jeff Kirsher take this via his tree. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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
