Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
On Monday, August 05, 2013 6:49:01 am Meny Yossefi wrote: John, Will this be committed to 9.2 as well ? Yes, I committed it yesterday. -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
John, Will this be committed to 9.2 as well ? -Meny -Original Message- From: j...@freebsd.org [mailto:j...@freebsd.org] Sent: Thursday, July 25, 2013 7:35 PM To: Meny Yossefi; j...@freebsd.org; freebsd-net@FreeBSD.org; j...@freebsd.org Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets State-Changed-From-To: open-patched State-Changed-By: jhb State-Changed-When: Thu Jul 25 16:34:38 UTC 2013 State-Changed-Why: Fix committed to HEAD, thanks! Responsible-Changed-From-To: freebsd-net-jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Jul 25 16:34:38 UTC 2013 Responsible-Changed-Why: Fix committed to HEAD, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=180430 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets State-Changed-From-To: open-patched State-Changed-By: jhb State-Changed-When: Thu Jul 25 16:34:38 UTC 2013 State-Changed-Why: Fix committed to HEAD, thanks! Responsible-Changed-From-To: freebsd-net-jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Jul 25 16:34:38 UTC 2013 Responsible-Changed-Why: Fix committed to HEAD, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=180430 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: Meny Yossefi me...@mellanox.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Date: Wed, 24 Jul 2013 13:14:53 +
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0EC13MTLDAG01mtlcom_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi John,
Looks good.
-Meny
From: Meny Yossefi
Sent: Tuesday, July 23, 2013 5:01 PM
To: 'John Baldwin'
Cc: 'bug-follo...@freebsd.org'
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
Let's stick with the FreeBSD standards (without the likely/unlikely)
Let me just double check the CSUM flags work as expected.
I'll get back to you as soon as I'm done.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Monday, July 22, 2013 7:04 PM
To: Meny Yossefi
Cc: bug-follo...@freebsd.orgmailto:bug-follo...@freebsd.org
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
On Monday, July 22, 2013 10:11:51 am Meny Yossefi wrote:
Hi John,
The problem is that the HW will only calculate csum for parts of the
payload, one fragment at a time,
while the receiver side, in our case the tcp/ip stack, will expect to val=
idate the packet's payload as a whole.
Ok.
I agree with the change you offered, though one thing bothers me.
This change will add two conditions to the send flow which will probably =
have an effect on performance.
Maybe 'likely' can be useful here ?
FreeBSD tends to not use likely/unlikely unless there is a demonstrable gai=
n via benchmark measurements. However, if the OFED code regularly uses it =
and you feel this is a case where you would normally use it, it can be adde=
d.
BTW, I'm not entirely sure, but I think the CSUM_IP flag is always set, s=
o maybe the first condition is not necessary.
What do you think ?
If the user uses ifconfig to disable checksum offload and force software ch=
ecksums the flag will not be set.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Friday, July 19, 2013 6:29 PM
To: bug-follo...@freebsd.orgmailto:bug-follo...@freebsd.org; Meny Yosse=
fi
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in th=
e packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_*
flags to determine the right settings. IP fragments will not have
CSUM_UDP or
CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- en_tx.c (revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags =3D
cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags
(CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |=3D cpu_to_be32=
(MLX4_WQE_CTRL_IP_CSUM |
-=
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags
+ (CSUM_TCP|CSUM_UDP))
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
--
John Baldwin
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0EC13MTLDAG01mtlcom_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml xmlns:o=3Durn:schemas-micr=
osoft-com:office:office xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; xmlns=3Dhttp:=
//www.w3.org/TR/REC-html40
head
meta http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii=
meta name=3DGenerator content=3DMicrosoft
RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: Meny Yossefi me...@mellanox.com
To: John Baldwin j...@freebsd.org
Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Date: Tue, 23 Jul 2013 14:01:23 +
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0D893MTLDAG01mtlcom_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Let's stick with the FreeBSD standards (without the likely/unlikely)
Let me just double check the CSUM flags work as expected.
I'll get back to you as soon as I'm done.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Monday, July 22, 2013 7:04 PM
To: Meny Yossefi
Cc: bug-follo...@freebsd.org
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
On Monday, July 22, 2013 10:11:51 am Meny Yossefi wrote:
Hi John,
The problem is that the HW will only calculate csum for parts of the
payload, one fragment at a time,
while the receiver side, in our case the tcp/ip stack, will expect to val=
idate the packet's payload as a whole.
Ok.
I agree with the change you offered, though one thing bothers me.
This change will add two conditions to the send flow which will probably =
have an effect on performance.
Maybe 'likely' can be useful here ?
FreeBSD tends to not use likely/unlikely unless there is a demonstrable gai=
n via benchmark measurements. However, if the OFED code regularly uses it =
and you feel this is a case where you would normally use it, it can be adde=
d.
BTW, I'm not entirely sure, but I think the CSUM_IP flag is always set, s=
o maybe the first condition is not necessary.
What do you think ?
If the user uses ifconfig to disable checksum offload and force software ch=
ecksums the flag will not be set.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Friday, July 19, 2013 6:29 PM
To: bug-follo...@freebsd.orgmailto:bug-follo...@freebsd.org; Meny Yosse=
fi
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in th=
e packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_*
flags to determine the right settings. IP fragments will not have
CSUM_UDP or
CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- en_tx.c (revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags =3D
cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags
(CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |=3D cpu_to_be32=
(MLX4_WQE_CTRL_IP_CSUM |
-=
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags
+ (CSUM_TCP|CSUM_UDP))
+
+ tx_desc-ctrl.srcrb_flags |=3D
+
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
--
John Baldwin
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0D893MTLDAG01mtlcom_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml xmlns:o=3Durn:schemas-micr=
osoft-com:office:office xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; xmlns=3Dhttp:=
//www.w3.org/TR/REC-html40
head
meta http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii=
meta name=3DGenerator content=3DMicrosoft Word 14 (filtered medium)
style!--
/* Font Definitions */
@font-face
{font-family:Cambria Math;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma
RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: Meny Yossefi me...@mellanox.com
To: John Baldwin j...@freebsd.org, bug-follo...@freebsd.org
bug-follo...@freebsd.org
Cc:
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Date: Mon, 22 Jul 2013 14:11:51 +
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0C0DAMTLDAG01mtlcom_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi John,
The problem is that the HW will only calculate csum for parts of the payloa=
d, one fragment at a time,
while the receiver side, in our case the tcp/ip stack, will expect to valid=
ate the packet's payload as a whole.
I agree with the change you offered, though one thing bothers me.
This change will add two conditions to the send flow which will probably ha=
ve an effect on performance.
Maybe 'likely' can be useful here ?
BTW, I'm not entirely sure, but I think the CSUM_IP flag is always set, so =
maybe the first condition is not necessary.
What do you think ?
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Friday, July 19, 2013 6:29 PM
To: bug-follo...@freebsd.org; Meny Yossefi
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment=
ed packets
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in the =
packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_* flags t=
o determine the right settings. IP fragments will not have CSUM_UDP or CSU=
M_TCP set, so I think the more correct fix is this:
Index: en_tx.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- en_tx.c (revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags =3D cpu_to_be32(MLX4_WQE_CTRL_CQ_U=
PDATE |
=
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags (CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |=3D cpu_to_be32(M=
LX4_WQE_CTRL_IP_CSUM |
- =
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+ tx_desc-ctrl.srcrb_flags |=
=3D
+ cpu_to_be32(MLX4_WQE_CTRL=
_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags (CSUM_TCP|CSUM_=
UDP))
+ tx_desc-ctrl.srcrb_flags |=
=3D
+ cpu_to_be32(MLX4_WQE_CTRL=
_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
--_000_F2E47A38E4D0B9499D76F2AB8901571A73A0C0DAMTLDAG01mtlcom_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml xmlns:o=3Durn:schemas-micr=
osoft-com:office:office xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; xmlns=3Dhttp:=
//www.w3.org/TR/REC-html40
head
meta http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii=
meta name=3DGenerator content=3DMicrosoft Word 14 (filtered medium)
style!--
/* Font Definitions */
@font-face
{font-family:Cambria Math;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Calibri,sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:Plain Text Char;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Calibri,sans-serif;}
span.PlainTextChar
{mso-style-name:Plain Text Char;
mso-style-priority:99;
mso-style-link:Plain Text;
font-family:Calibri,sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri,sans-serif
Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: Meny Yossefi me...@mellanox.com
Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented
packets
Date: Mon, 22 Jul 2013 11:40:08 -0400
On Monday, July 22, 2013 10:11:51 am Meny Yossefi wrote:
Hi John,
The problem is that the HW will only calculate csum for parts of the
payload, one fragment at a time,
while the receiver side, in our case the tcp/ip stack, will expect to
validate the packet's payload as a whole.
Ok.
I agree with the change you offered, though one thing bothers me.
This change will add two conditions to the send flow which will probably
have an effect on performance.
Maybe 'likely' can be useful here ?
FreeBSD tends to not use likely/unlikely unless there is a demonstrable gain
via benchmark measurements. However, if the OFED code regularly uses it and
you feel this is a case where you would normally use it, it can be added.
BTW, I'm not entirely sure, but I think the CSUM_IP flag is always set, so
maybe the first condition is not necessary.
What do you think ?
If the user uses ifconfig to disable checksum offload and force software
checksums the flag will not be set.
-Meny
-Original Message-
From: John Baldwin [mailto:j...@freebsd.org]
Sent: Friday, July 19, 2013 6:29 PM
To: bug-follo...@freebsd.org; Meny Yossefi
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in the
packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_* flags to
determine the right settings. IP fragments will not have CSUM_UDP or
CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
===
--- en_tx.c (revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags =
cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags (CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |=
cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
-
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+ tx_desc-ctrl.srcrb_flags |=
+
cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags
(CSUM_TCP|CSUM_UDP))
+ tx_desc-ctrl.srcrb_flags |=
+
cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: bug-follo...@freebsd.org,
me...@mellanox.com
Cc:
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented
packets
Date: Fri, 19 Jul 2013 11:13:44 -0400
Oops, my previous reply didn't make it to the PR itself.
Is the problem that the hardware checksum overwrites arbitrary data in the
packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_*
flags to determine the right settings. IP fragments will not have
CSUM_UDP or CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
===
--- en_tx.c(revision 253470)
+++ en_tx.c(working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags = cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags (CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
-
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+ tx_desc-ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags (CSUM_TCP|CSUM_UDP))
+ tx_desc-ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
On Wednesday, July 10, 2013 6:59:42 am lini...@freebsd.org wrote:
Old Synopsis: Bad UDP checksum calc for fragmented packets
New Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Jul 10 10:59:03 UTC 2013
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=180430
Is the problem that the hardware checksum overwrites arbitrary data in the
packet (at the location where the UDP header would be)?
Also, I've looked at other drivers, and they all look at the CSUM_*
flags to determine the right settings. IP fragments will not have
CSUM_UDP or CSUM_TCP set, so I think the more correct fix is this:
Index: en_tx.c
===
--- en_tx.c (revision 253202)
+++ en_tx.c (working copy)
@@ -780,8 +780,12 @@ retry:
tx_desc-ctrl.srcrb_flags = cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE |
MLX4_WQE_CTRL_SOLICITED);
if (mb-m_pkthdr.csum_flags (CSUM_IP|CSUM_TCP|CSUM_UDP)) {
- tx_desc-ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
-
MLX4_WQE_CTRL_TCP_UDP_CSUM);
+ if (mb-m_pkthdr.csum_flags CSUM_IP)
+ tx_desc-ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb-m_pkthdr.csum_flags (CSUM_TCP|CSUM_UDP)) {
+ tx_desc-ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
priv-port_stats.tx_chksum_offload++;
}
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets
Old Synopsis: Bad UDP checksum calc for fragmented packets New Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 10 10:59:03 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180430 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
