diff mbox

[net-next,2/3] ixgbe: Distribute transmission of FCoE traffic in 82599

Message ID 20090904005609.14869.89202.stgit@localhost.localdomain
State Accepted, archived
Delegated to: David Miller
Headers show

Commit Message

Kirsher, Jeffrey T Sept. 4, 2009, 12:56 a.m. UTC 
From: Yi Zou <yi.zou@intel.com>

This adds a simple selection of a FCoE tx queue based on the current cpu id to
distribute transmission of FCoE traffic evenly among multiple FCoE transmit
queues.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

David Miller Sept. 4, 2009, 3:09 a.m. UTC | #1 
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:56:10 -0700

> From: Yi Zou <yi.zou@intel.com>
> 
> This adds a simple selection of a FCoE tx queue based on the current cpu id to
> distribute transmission of FCoE traffic evenly among multiple FCoE transmit
> queues.
> 
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

Does it matter that arbitrary programs or other stacks could transmit
ETH_P_FCOE traffic as well?  Would that interfere with how this offload
hardware works now that you're directing all ETH_P_FCOE traffic to
FCOE rings?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Waskiewicz Jr, Peter P Sept. 4, 2009, 4:12 a.m. UTC | #2 
On Thu, 3 Sep 2009, David Miller wrote:

> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 03 Sep 2009 17:56:10 -0700
> 
> > From: Yi Zou <yi.zou@intel.com>
> > 
> > This adds a simple selection of a FCoE tx queue based on the current cpu id to
> > distribute transmission of FCoE traffic evenly among multiple FCoE transmit
> > queues.
> > 
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> 
> Applied.
> 
> Does it matter that arbitrary programs or other stacks could transmit
> ETH_P_FCOE traffic as well?  Would that interfere with how this offload
> hardware works now that you're directing all ETH_P_FCOE traffic to
> FCOE rings?

If another stack uses the FCoE Ethertype, the filtering we use in the 
qdisc layer to filter FCoE frames would assume they belong in the FCoE 
flow ID in the driver.  As long as the other stacks send standard FCoE 
frames, there won't be a problem.  If a stack uses the Ethertype but 
doesn't follow the standard FCoE frame format, then I'd say that stack was 
in need of being fixed.

The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.

Cheers,
-PJ
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yi Zou Sept. 4, 2009, 5:07 a.m. UTC | #3 
>On Thu, 3 Sep 2009, David Miller wrote:
>
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Thu, 03 Sep 2009 17:56:10 -0700
>>
>> > From: Yi Zou <yi.zou@intel.com>
>> >
>> > This adds a simple selection of a FCoE tx queue based on the current cpu
>id to
>> > distribute transmission of FCoE traffic evenly among multiple FCoE
>transmit
>> > queues.
>> >
>> > Signed-off-by: Yi Zou <yi.zou@intel.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Applied.
>>
>> Does it matter that arbitrary programs or other stacks could transmit
>> ETH_P_FCOE traffic as well?  Would that interfere with how this offload
>> hardware works now that you're directing all ETH_P_FCOE traffic to
>> FCOE rings?
>
>If another stack uses the FCoE Ethertype, the filtering we use in the
>qdisc layer to filter FCoE frames would assume they belong in the FCoE
>flow ID in the driver.  As long as the other stacks send standard FCoE
>frames, there won't be a problem.  If a stack uses the Ethertype but
>doesn't follow the standard FCoE frame format, then I'd say that stack was
>in need of being fixed.
>
>The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.
>
>Cheers,
>-PJ
Yes, any stack that wants to take advantage of 82599's FCoE offload
capability has to fake its traffic as FCoE frames.

Thanks,
yi

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 724754a..45bf8b9 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -5168,9 +5168,15 @@  static netdev_tx_t ixgbe_xmit_frame(struct sk_buff *skb,
 	tx_ring = &adapter->tx_ring[r_idx];
 
 	if ((adapter->flags & IXGBE_FLAG_FCOE_ENABLED) &&
-	    (skb->protocol == htons(ETH_P_FCOE)))
+	    (skb->protocol == htons(ETH_P_FCOE))) {
 		tx_flags |= IXGBE_TX_FLAGS_FCOE;
-
+#ifdef IXGBE_FCOE
+		r_idx = smp_processor_id();
+		r_idx &= (adapter->ring_feature[RING_F_FCOE].indices - 1);
+		r_idx += adapter->ring_feature[RING_F_FCOE].mask;
+		tx_ring = &adapter->tx_ring[r_idx];
+#endif
+	}
 	/* four things can cause us to need a context descriptor */
 	if (skb_is_gso(skb) ||
 	    (skb->ip_summed == CHECKSUM_PARTIAL) ||