public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Vadim Makhervaks
	<vadim.makhervaks-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Subject: Re: ib_ipoib: CSUM support in connected mode
Date: Tue, 30 Sep 2014 11:39:20 +0300	[thread overview]
Message-ID: <20140930083920.GA7178@yuval-lab> (raw)
In-Reply-To: <20140922192802.GB3425@yuval-lab>

On Mon, Sep 22, 2014 at 10:28:02PM +0300, Yuval Shaia wrote:
> On Tue, Sep 16, 2014 at 09:47:43AM +0300, Or Gerlitz wrote:
> > 
> > On 9/15/2014 9:55 PM, Yuval Shaia wrote:
> > >On Mon, Sep 15, 2014 at 05:47:19PM +0300, Or Gerlitz wrote:
> > >>>On Sun, Sep 14, 2014 at 9:46 PM, Yuval Shaia<yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>  wrote:
> > >>>>>By default, IPoIB-CM driver uses 64k MTU. Larger MTU gives better performance.
> > >>>>>This MTU plus overhead puts the memory allocation for IP based packets at 32 4k pages (order 5),
> > >>
> > >>>So if we make sure that the advertized netdevice MTU is 64K minus that
> > >>>over head we're back to order four
> > >>>allocation and problem is solved?   note that RFC 4755 makes sure that
> > >>>the MTU is negotiated in both directions,
> > >>>so it can have any value, specifically 64K - that epsilon which will
> > >>>hopefully make you happy
> > >Interesting point. But please note that in any case, when not using scatter/gather we force the allocation of large contiguous physical memory.
> > 
> > On the post you wrote "[...] resolve the issue by removing the physically contiguous memory requirement using Scatter/Gather feature that exists in Linux".
> > 
> > I assume you refer to NETIF_F_SG, right? so your claim is that Linux will not effectively use the driver ability to serve SG skbs unless the driver also advertizes (say) NETIF_F_IP_CSUM?!
> > 
> > I thought it's the other way around -- that is supporting checksum offloading is useless unless SG is supported. Can you provide pointer into the network stack code/documentation that supports your claim?
> > Or.
> While porting the patch to latest kernel i have learned that this limitation is no longer exist.
> The limitation i was talking about was in older versions of the function netdev_fix_features().
> 	/* Fix illegal SG+CSUM combinations. */
> 	if ((features & NETIF_F_SG) &&
> 	    !(features & NETIF_F_ALL_CSUM)) {
> 		netdev_dbg(dev,
> 			"Dropping NETIF_F_SG since no checksum feature.\n");
> 		features &= ~NETIF_F_SG;
> 	}
> Now, with the removal of this limitation the argument of "...In order to use SG....IPoIB-CM must support IP checksum offload" is no longer applicable.
> We now left with the performance benefit argument only, can we ignore the performance improvement achieved by eliminating the need to calculate checksum in SW?
Another benefit we should take into account is that that IB-CRC is **much more** reliable than checksum!!
> > 
> > 
> > 
--
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

  reply	other threads:[~2014-09-30  8:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-14 18:46 ib_ipoib: CSUM support in connected mode Yuval Shaia
2014-09-15 14:47 ` Or Gerlitz
     [not found]   ` <CAJ3xEMhEzdyzcAufQU--VbM7aoAzsw7wV2i_i=kjcS9PbdC0Tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-15 16:58     ` Jason Gunthorpe
     [not found]       ` <20140915165820.GB12397-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2014-09-15 17:20         ` Or Gerlitz
     [not found]           ` <CAJ3xEMir_FgqS7j+fuhugocawdZXHG9hAK-jpArZ_5vkzVjZeg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-15 17:45             ` Jason Gunthorpe
2014-09-15 19:03         ` Yuval Shaia
2014-09-15 18:55     ` Yuval Shaia
2014-09-16  6:47       ` Or Gerlitz
     [not found]         ` <5417DD0F.9090201-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-09-22 19:28           ` Yuval Shaia
2014-09-30  8:39             ` Yuval Shaia [this message]
2014-10-02 13:00           ` Yuval Shaia
2014-10-01 11:55 ` Yuval Shaia
2014-10-01 12:13   ` Or Gerlitz
     [not found]     ` <542BEFED.6050203-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-10-04 18:36       ` 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=20140930083920.GA7178@yuval-lab \
    --to=yuval.shaia-qhclzuegtsvqt0dzr+alfa@public.gmane.org \
    --cc=gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
    --cc=vadim.makhervaks-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