Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[David Miller]

You can't put things like "[3.4]" unquoted into the CC: list, that's
not kosher and vger rejected it.

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Tue, 2012-06-26 at 00:43 -0700, David Miller wrote:
> You can't put things like "[3.4]" unquoted into the CC: list, that's
> not kosher and vger rejected it.

Sorry, that was what Greg told me to do.  I did not realize it needed to
be in quotes, my bad.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

On Tue, 2012-06-26 at 00:43 -0700, David Miller wrote:
> You can't put things like "[3.4]" unquoted into the CC: list, that's
> not kosher and vger rejected it.

Re-sent with the proper quoting.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[David Miller]

Sorry, quotes don't work either, what you did is still a SMTP syntax error,
here's what is in the bounce I get back:

	<stable@vger.kernel.org> "[3.4]",
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Illegal-Object:	Syntax error in Cc: address found on vger.kernel.org:
	Cc:	<stable@vger.kernel.org>"[3.4]"
						^-missing end of address

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 26 Jun 2012 00:49:40 -0700

> On Tue, 2012-06-26 at 00:43 -0700, David Miller wrote:
>> You can't put things like "[3.4]" unquoted into the CC: list, that's
>> not kosher and vger rejected it.
> 
> Re-sent with the proper quoting.

Doesn't work, see my reply.

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Tue, 2012-06-26 at 00:50 -0700, David Miller wrote:
> Sorry, quotes don't work either, what you did is still a SMTP syntax error,
> here's what is in the bounce I get back:
> 
> 	<stable@vger.kernel.org> "[3.4]",
> 	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Illegal-Object:	Syntax error in Cc: address found on vger.kernel.org:
> 	Cc:	<stable@vger.kernel.org>"[3.4]"
> 						^-missing end of address

Grrr...

I will re-send without the "[3.4]", Greg will just have to deal with it.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Jeff Kirsher]

From: Alexander Duyck <alexander.h.duyck@intel.com>

FCoE target mode was experiencing issues due to the fact that we were
sending up data frames that were padded to 60 bytes after the DDP logic had
already stripped the frame down to 52 or 56 depending on the use of VLANs.
This was resulting in the FCoE DDP logic having issues since it thought the
frame still had data in it due to the padding.

To resolve this, adding code so that we do not pad FCoE frames prior to
handling them to the stack.

CC: <stable@vger.kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h      |    4 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c  |    2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   14 ++++++++++----
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 3ef3c52..7af291e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -196,7 +196,7 @@ enum ixgbe_ring_state_t {
 	__IXGBE_HANG_CHECK_ARMED,
 	__IXGBE_RX_RSC_ENABLED,
 	__IXGBE_RX_CSUM_UDP_ZERO_ERR,
-	__IXGBE_RX_FCOE_BUFSZ,
+	__IXGBE_RX_FCOE,
 };
 
 #define check_for_tx_hang(ring) \
@@ -290,7 +290,7 @@ struct ixgbe_ring_feature {
 #if defined(IXGBE_FCOE) && (PAGE_SIZE < 8192)
 static inline unsigned int ixgbe_rx_pg_order(struct ixgbe_ring *ring)
 {
-	return test_bit(__IXGBE_RX_FCOE_BUFSZ, &ring->state) ? 1 : 0;
+	return test_bit(__IXGBE_RX_FCOE, &ring->state) ? 1 : 0;
 }
 #else
 #define ixgbe_rx_pg_order(_ring) 0
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index af1a531..c377706 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -634,7 +634,7 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter *adapter,
 			f = &adapter->ring_feature[RING_F_FCOE];
 			if ((rxr_idx >= f->mask) &&
 			    (rxr_idx < f->mask + f->indices))
-				set_bit(__IXGBE_RX_FCOE_BUFSZ, &ring->state);
+				set_bit(__IXGBE_RX_FCOE, &ring->state);
 		}
 
 #endif /* IXGBE_FCOE */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbb05d6..18ca3bc 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1058,17 +1058,17 @@ static inline void ixgbe_rx_hash(struct ixgbe_ring *ring,
 #ifdef IXGBE_FCOE
 /**
  * ixgbe_rx_is_fcoe - check the rx desc for incoming pkt type
- * @adapter: address of board private structure
+ * @ring: structure containing ring specific data
  * @rx_desc: advanced rx descriptor
  *
  * Returns : true if it is FCoE pkt
  */
-static inline bool ixgbe_rx_is_fcoe(struct ixgbe_adapter *adapter,
+static inline bool ixgbe_rx_is_fcoe(struct ixgbe_ring *ring,
 				    union ixgbe_adv_rx_desc *rx_desc)
 {
 	__le16 pkt_info = rx_desc->wb.lower.lo_dword.hs_rss.pkt_info;
 
-	return (adapter->flags & IXGBE_FLAG_FCOE_ENABLED) &&
+	return test_bit(__IXGBE_RX_FCOE, &ring->state) &&
 	       ((pkt_info & cpu_to_le16(IXGBE_RXDADV_PKTTYPE_ETQF_MASK)) ==
 		(cpu_to_le16(IXGBE_ETQF_FILTER_FCOE <<
 			     IXGBE_RXDADV_PKTTYPE_ETQF_SHIFT)));
@@ -1549,6 +1549,12 @@ static bool ixgbe_cleanup_headers(struct ixgbe_ring *rx_ring,
 		skb->truesize -= ixgbe_rx_bufsz(rx_ring);
 	}
 
+#ifdef IXGBE_FCOE
+	/* do not attempt to pad FCoE Frames as this will disrupt DDP */
+	if (ixgbe_rx_is_fcoe(rx_ring, rx_desc))
+		return false;
+
+#endif
 	/* if skb_pad returns an error the skb was freed */
 	if (unlikely(skb->len < 60)) {
 		int pad_len = 60 - skb->len;
@@ -1775,7 +1781,7 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
 
 #ifdef IXGBE_FCOE
 		/* if ddp, not passing to ULD unless for FCP_RSP or error */
-		if (ixgbe_rx_is_fcoe(adapter, rx_desc)) {
+		if (ixgbe_rx_is_fcoe(rx_ring, rx_desc)) {
 			ddp_bytes = ixgbe_fcoe_ddp(adapter, rx_desc, skb);
 			if (!ddp_bytes) {
 				dev_kfree_skb_any(skb);
-- 
1.7.10.2

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Tue, 2012-06-26 at 00:53 -0700, Jeff Kirsher wrote:
> On Tue, 2012-06-26 at 00:50 -0700, David Miller wrote:
> > Sorry, quotes don't work either, what you did is still a SMTP syntax error,
> > here's what is in the bounce I get back:
> > 
> > 	<stable@vger.kernel.org> "[3.4]",
> > 	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Illegal-Object:	Syntax error in Cc: address found on vger.kernel.org:
> > 	Cc:	<stable@vger.kernel.org>"[3.4]"
> > 						^-missing end of address
> 
> Grrr...
> 
> I will re-send without the "[3.4]", Greg will just have to deal with it.

It's certainly not necessary to put anything like that in the real Cc
header. Many people put something like
'Cc: <stable@vger.kernel.org> # 3.4' in the body; I don't know if that
is more like likely to result in the version being stripped when
generating mail recipients.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Alexander Duyck]

On 06/26/2012 07:09 AM, Ben Hutchings wrote:
> On Tue, 2012-06-26 at 00:53 -0700, Jeff Kirsher wrote:
>> On Tue, 2012-06-26 at 00:50 -0700, David Miller wrote:
>>> Sorry, quotes don't work either, what you did is still a SMTP syntax error,
>>> here's what is in the bounce I get back:
>>>
>>> 	<stable@vger.kernel.org> "[3.4]",
>>> 	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> Illegal-Object:	Syntax error in Cc: address found on vger.kernel.org:
>>> 	Cc:	<stable@vger.kernel.org>"[3.4]"
>>> 						^-missing end of address
>> Grrr...
>>
>> I will re-send without the "[3.4]", Greg will just have to deal with it.
> It's certainly not necessary to put anything like that in the real Cc
> header. Many people put something like
> 'Cc: <stable@vger.kernel.org> # 3.4' in the body; I don't know if that
> is more like likely to result in the version being stripped when
> generating mail recipients.
>
> Ben.
>
Couldn't 3.4 have been put in place of the recipient's name?  So you do
something like this:
Cc: 3.4 <stable@vger.kernel.org>

Thanks,

Alex

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Tue, 2012-06-26 at 08:48 -0700, Alexander Duyck wrote:
> On 06/26/2012 07:09 AM, Ben Hutchings wrote:
> > On Tue, 2012-06-26 at 00:53 -0700, Jeff Kirsher wrote:
> >> On Tue, 2012-06-26 at 00:50 -0700, David Miller wrote:
> >>> Sorry, quotes don't work either, what you did is still a SMTP syntax error,
> >>> here's what is in the bounce I get back:
> >>>
> >>> 	<stable@vger.kernel.org> "[3.4]",
> >>> 	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >>> Illegal-Object:	Syntax error in Cc: address found on vger.kernel.org:
> >>> 	Cc:	<stable@vger.kernel.org>"[3.4]"
> >>> 						^-missing end of address
> >> Grrr...
> >>
> >> I will re-send without the "[3.4]", Greg will just have to deal with it.
> > It's certainly not necessary to put anything like that in the real Cc
> > header. Many people put something like
> > 'Cc: <stable@vger.kernel.org> # 3.4' in the body; I don't know if that
> > is more like likely to result in the version being stripped when
> > generating mail recipients.
> >
> > Ben.
> >
> Couldn't 3.4 have been put in place of the recipient's name?  So you do
> something like this:
> Cc: 3.4 <stable@vger.kernel.org>

Aside from the fact that recipient names with dots must be quoted in the
real header, it's relatively uncommon to use this format and the import
script I use for 3.2.y wouldn't notice it.  (So I'd have to go back and
look at the original commit header to work out that it wasn't relevant.)
I don't know whether Greg's script extracts the recipient name.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[Greg KH]

On Tue, Jun 26, 2012 at 12:47:30AM -0700, Jeff Kirsher wrote:
> On Tue, 2012-06-26 at 00:43 -0700, David Miller wrote:
> > You can't put things like "[3.4]" unquoted into the CC: list, that's
> > not kosher and vger rejected it.
> 
> Sorry, that was what Greg told me to do.  I did not realize it needed to
> be in quotes, my bad.

Greg told you no such thing, please use real email addresses on your cc:
lines, to not do so is crazy, and to blame me is sad.

greg k-h

Re: [net] ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 26 Jun 2012 00:54:46 -0700

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> FCoE target mode was experiencing issues due to the fact that we were
> sending up data frames that were padded to 60 bytes after the DDP logic had
> already stripped the frame down to 52 or 56 depending on the use of VLANs.
> This was resulting in the FCoE DDP logic having issues since it thought the
> frame still had data in it due to the padding.
> 
> To resolve this, adding code so that we do not pad FCoE frames prior to
> handling them to the stack.
> 
> CC: <stable@vger.kernel.org>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Tested-by: Ross Brattain <ross.b.brattain@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied, thanks.