From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] IB/ipoib: CSUM support in connected mode
Date: Mon, 23 Nov 2015 11:29:57 -0700 [thread overview]
Message-ID: <20151123182957.GC32085@obsidianresearch.com> (raw)
In-Reply-To: <20151118202740.GA3262@yuval-lab>
On Wed, Nov 18, 2015 at 10:27:41PM +0200, Yuval Shaia wrote:
> > You need private-data exchange to negotiate the feature.
> >
> > The feature should be a per-packet csum status header.
> >
> > When sending a skb that is already fully csumed the receiver sets
> > CHECKSUM_UNNECESSARY.
> >
> > When sending a skb that has CHECKSUM_PARTIAL then the
> > receiver needs to call skb_partial_csum_set.
> >
> > Look at how something like VIRTIO_NET_HDR_F_NEEDS_CSUM works and copy
> > that scheme.
> Correct me if i'm wrong here but isn't this protocol assume both parties
> are aware of this special header?
Yes.
No matter what you do both sides must be aware of the change in
protocol, doing it correctly requires adding a small wire header to
flow through the checksum state. This would be enabled once
negotiation confirms both sides will support this.
> My case is a bit different, driver must support backward
> computability in a way that peer maybe a driver that do not support
> this feature and expect packet to be full checksummed.
This is why negotiation is mandatory.
> > DO NOT EVER set CHECKSUM_UNNECESSARY on packets that do not have valid
> > csums - that breaks the net stack.
> The entire idea here is to fake csum offload so how would i tell the stack
> not to run csum on incoming packet?
I already explained this, call skb_partial_csum_set and the stack will
avoid csum work.
> > Yes, you need to add a header to all packets to support this scheme,
> > that is what the private-data negotiation is for.
> >
> > While you are at it, I'd make room for something like
> > VIRTIO_NET_HDR_GSO_* in the RC protocol too. Implementing GSO
> > forwarding is probably another big performance win.
> If i understood you correctly and you mean exchange of
> "driver-capabilities", then yes, it is there with the extends of
> ipoib_cm_data structure.
You need to dig into how the things I referenced above work, fully
understand them and then adapt them to IPoIB.
Jason
--
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-11-23 18:29 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
[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 [this message]
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=20151123182957.GC32085@obsidianresearch.com \
--to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).