From owner-freebsd-hackers@freebsd.org Sat May 26 14:10:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0898EF7711A for ; Sat, 26 May 2018 14:10:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8098770F1D for ; Sat, 26 May 2018 14:10:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id f21-v6so9453766iob.13 for ; Sat, 26 May 2018 07:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bm7j3enUwTCfcD7tUpD90kbMbLVkp/d2uM4ddHijAXI=; b=KSyCgN/M2pgaqpwdw3D6srutkQv7RKM4tIfL7jWFLcGToMK/G72xFFzj7Xs8mT3tKs DeMgZaGPW3W7zFPawZcc/nr7lHp4gtoEuh7GdaNebVQeA7FPk7EBgDF/J4e+l0317tAY 9i3YIhI4LA9bKU3KoOpnSNO/SJK6Vz+vtvh1cSO9ijwsdUfpKrRujGJwSxEkvSRsJO+h 47KbS4Y/bglaDsFzh2M10nn1tWZ5/O4tYY5mz1UiAVxCXPTwQtC+0ShqVDYT0vf10jcH 2ymeTRfZwPdWHfXcq4VOvXn1ntMTzCFZBAqFe1T1xrB3fCVjj93u1as6MAY41OxkJbdl 8yyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bm7j3enUwTCfcD7tUpD90kbMbLVkp/d2uM4ddHijAXI=; b=X0ScTqewqzYUTLWzcHHtsLQiJ86HVkFkELFeEApOdS37+iR8SicmJnZvaWtZizldtG Q9V4jst97goiMDEkYgbqvfMRxD13dyZYCPn5vCSdLxcFjfGgHH6Ept7Jrc/A5EDQD5Lh wmFp5+u76WWnmdGCYFyexodmonwOZvtvBbNg0Femc3kq11MX3+L23k9B9qnRI9169QpG RvMtsK8b0RmPfs1G9DnogUvmvBjiyrgsGsaipqz9388fLIHx0QzLB2RS7pODaCGLe4Mc xRQ9glEG0L6AWqeBl4Ngx3W0fzLCKGLYztO7BKcQQ3YJTMKS99pv7bwj0Ehn+Mj3cjZ2 W1bw== X-Gm-Message-State: ALKqPwe1CxPeCkAEkN55tm8s8luqR8fWQk1PJAJf1v+QamrK9MdX9NmL GYq+WEcb461cG+dhHhN9LXk59eDQJGYW/ISBzlb0hw== X-Google-Smtp-Source: ADUXVKKidq1rNIe7PqKT/dAJPghEq6y7p9a7CzEjkA1hul6r0lj5ZtOWHdxKK6drm8dAhdhMzWgg1bu/7F/Rrv+Hs5s= X-Received: by 2002:a6b:1c87:: with SMTP id c129-v6mr539550ioc.39.1527343829800; Sat, 26 May 2018 07:10:29 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:d028:0:0:0:0:0 with HTTP; Sat, 26 May 2018 07:10:29 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: From: Warner Losh Date: Sat, 26 May 2018 08:10:29 -0600 X-Google-Sender-Auth: fBYKPfyfUxMogUkn2HxkaeTnIN8 Message-ID: Subject: Re: Why is there no bus_dmamap_load_sg()? To: Pratyush Yadav Cc: "freebsd-hackers@freebsd.org" , Akshay Jaggi , Edward Napierala Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 14:10:31 -0000 On Sat, May 26, 2018 at 3:07 AM, Pratyush Yadav wrote: > I was looking at the man page and I notice the function > bus_dmamap_load_mbuf_sg() which directly returns the segment array to > the client. But a similar variant of bus_dmamap_load() is missing. > This variant would be useful to me and help me in my work. > > Is there a reason the sg variant was only implemented for mbufs? > > I was looking at the code in sys/kern/subr_bus_dma.c and a > bus_dmamap_load_sg() does not look too difficult to implement. Is it > ok if I submit a patch implementing it? > The biggest reason is because of the failure modes. If there's not sufficient memory or other resources to honor the request, we defer until there is such memory / resources and then call the callback. There's no convenient hook the drivers can connect to so they can retry the allocation when memory becomes available (busdma has one since eventually a request will complete and unload). The original port was for CAM SIMs which had stringent requirements to always make progress on I/Os to avoid deadlock. Rather than put this tricky code in all the CAM SIMs, it's centralized to retry as soon and as robustly as it can. Network drivers, however, don't have such requirements and often don't care. If they can't load a map, they can put the packet back on the transmit queue (or whatever), set a flag and return without putting it into the NIC's buffer rings. Eventually, a packet will finish transmitting and there will be a chance to send it again (or one of a number of other events, I'm glossing heavily here). It's a better fit for network drivers than storage drivers. Since bus_dmamap_load_mbuf* is used only for network drivers, it makes sense. So, it would only make sense to add if you can cope with BUS_DMA_NOWAIT always, and that error handling is simpler than letting busdma call you back when the shortage is over. Is that the case for your port? Or is it just because OpenBSD doesn't have this sort of interface (the callback difference dates back to the initial port to FreeBSD by Justin Gibbs because it never got folded back into NetBSD for reasons too long, too old and only half remembered by me for this post)? Can the code you are porting cope with error returns and retry again later? Warner