From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [PATCH v1 01/24] IB/core: Introduce new fast registration API Date: Tue, 29 Sep 2015 09:47:59 +0300 Message-ID: <560A341F.7030108@mellanox.com> References: <1442482947-27785-1-git-send-email-sagig@mellanox.com> <1442482947-27785-2-git-send-email-sagig@mellanox.com> <5601C65F.8060403@sandisk.com> <5603A841.70509@dev.mellanox.co.il> <5609A9D0.8030607@sandisk.com> <20150929055907.GA29758@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150929055907.GA29758-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig , Bart Van Assche Cc: Sagi Grimberg , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Nicholas A. Bellinger" List-Id: linux-rdma@vger.kernel.org > Shouldn't higher layers take care of this? Trying to implement the same > coalescing algorithm at various layers isn't very optimal, although we > need to decide and document which one is responsible. The block layer can take care of it, but I'm not sure about NFS/RDS at the moment (IIRC Steve specifically asked if this API would take care of chunking contig sg elements) so I'd rather keep it in until we are absolutely sure we don't need it. I can add a documentation statement for it. -- 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