From: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
To: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] IB/ipoib: CSUM support in connected mode
Date: Thu, 30 Jul 2015 15:58:13 +0200 [thread overview]
Message-ID: <1438264693.9344.19.camel@opteya.com> (raw)
In-Reply-To: <1438256764-9077-1-git-send-email-yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi,
Le jeudi 30 juillet 2015 à 04:46 -0700, Yuval Shaia a écrit :
> This enhancement suggest the usage of IB CRC instead of CSUM in IPoIB
> CM. IPoIB CM uses RC (Reliable Connection) which guarantees the
> corruption free delivery of the packet.
>
> InfiniBand uses 32b CRC which provides stronger data integrity
> protection compare to 16b IP Checksum.
InfiniBand 32b CRC <=> Ethernet 32b CRC, it's link layer, layer 2.
IPv4 checksum is at another level, it's internet layer, layer 3.
> So, there is no added value that IP/TCP Checksum provides in the IB
> world.
>
Sure, IPv4 checksum is a thing of the past: checksum was dropped from
IP header in IPv6: it assumes the lower layer, such as Ethernet,
provides the required integrety check.
I think not checking the IPv4 checksum should be a choice, carefully
thought, for inside a fabric, as I understand your proposal, packet
with invalid checksum will be allowed to go in/out of the fabric.
It sound like it's a departure from the behavior one can expect from an
IPv4 network stack.
> The proposal is to tell network stack that IPoIB-CM supports IP
> Checksum offload. This enables the kernel to save the time of
> checksum calculation of IPoIB CM packets. Network sends the IP packet
> without adding the IP Checksum to the header. On the receive side,
> IPoIB driver again tells the network stack that IP Checksum is good
> for the incoming packets and network stack avoids the IP Checksum
> calculations.
>
> During connection establishment the driver determine if peer supports
> IB CRC as checksum. This is done so driver will be able to calculate
> checksum before transmiting the packet in case the peer does not
> support this feature.
>
Two questions:
- What will see tool such as wireshark/tcpdump when sniffing checksum
-less IPv4 packets sent/received on IPoIB interface ?
- What might happen if such checksum-less IPv4 packet is later routed to a different IPv4 network ?
> With this enhancement throughput is increased by 60%.
>
> Signed-off-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-07-30 13:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 11:46 [PATCH] IB/ipoib: CSUM support in connected mode Yuval Shaia
[not found] ` <1438256764-9077-1-git-send-email-yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2015-07-30 13:58 ` Yann Droneaud [this message]
[not found] ` <1438264693.9344.19.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-07-30 15:20 ` Yuval Shaia
2015-07-30 15:51 ` Doug Ledford
[not found] ` <55BA47F0.5080504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-30 17:15 ` Jason Gunthorpe
[not found] ` <20150730171538.GA25282-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-07-30 20:46 ` Yuval Shaia
2015-07-30 21:00 ` Jason Gunthorpe
[not found] ` <20150730210018.GA32451-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-11-18 20:27 ` Yuval Shaia
2015-11-23 18:29 ` Jason Gunthorpe
2015-07-30 20:37 ` Yuval Shaia
2015-11-18 10:46 ` Yuval Shaia
2015-11-24 9:45 ` Yann Droneaud
[not found] ` <1448358314.19858.13.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-11-24 18:59 ` Jason Gunthorpe
2015-07-30 16:38 ` Bart Van Assche
[not found] ` <55BA531E.6060403-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-07-30 20:09 ` Yuval Shaia
2015-07-31 2:03 ` Bart Van Assche
[not found] ` <55BAD76A.1070700-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-09-03 20:29 ` Doug Ledford
[not found] ` <55E8ADB9.4090900-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-06 11:27 ` Yuval Shaia
2015-11-18 10:27 ` Yuval Shaia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1438264693.9344.19.camel@opteya.com \
--to=ydroneaud-rly5vtjfyj3qt0dzr+alfa@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.