From owner-freebsd-arch@FreeBSD.ORG Mon Sep 8 10:39:14 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB4706A5; Mon, 8 Sep 2014 10:39:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4364A183B; Mon, 8 Sep 2014 10:39:14 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s88Ad8as054079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2014 13:39:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s88Ad8as054079 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s88Ad8Vv054078; Mon, 8 Sep 2014 13:39:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Sep 2014 13:39:08 +0300 From: Konstantin Belousov To: Jean-S??bastien P??dron Subject: Re: Linux kernel API wrapper: using OFED's one in other drivers Message-ID: <20140908103908.GZ2737@kib.kiev.ua> References: <540D7D91.9000104@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+9Mf+ORMRPqeJE8p" Content-Disposition: inline In-Reply-To: <540D7D91.9000104@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 10:39:14 -0000 --+9Mf+ORMRPqeJE8p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 08, 2014 at 11:57:37AM +0200, Jean-S??bastien P??dron wrote: > Hi! >=20 > OFED (sys/ofed) comes with a Linux kernel API wrapper. Beside OFED > itself, it's currently used in sys/dev/cxgb and sys/dev/cxgbe. >=20 > I'm playing with this wrapper to add a new feature to the i915 GPU > driver [1]. Don't pay attention to the current patch as this is not the > final approach I have in mind. However, the idea is there: I'd like to > use it in sys/dev/drm2. >=20 > The benefit of using such a wrapper in the DRM drivers are obvious: > 1. It greatly reduces the diff between FreeBSD code and Linux > original code. See below. > 2. It speeds up the integration of new changes in FreeBSD. > 3. It eases the report of bugfixes to Linux. >=20 > Those arguments are true for any driver. But in this particular case, > this would allow us to reduce the gap with Linux in the graphics stack > area more quickly (and we deeply need that). DragonFlyBSD is already > doing that. >=20 > Of course, using this wrapper as it is today isn't practicle: the code > is located in a driver and it's not even part of GENERIC. The proposal > is to move it outside of OFED and add it to GENERIC. >=20 > I don't have a patch to show yet. I'd like to get feedback first. What > do you think about that? OFED maintainers, would you be ok? >=20 > [1] https://wiki.freebsd.org/Graphics/Add_HW_context_support_to_i915 My main objections to use OFED wrappers for drm2 are: 1. It tightly binds different drivers with non-coordinating maintainers to the version of the Linux KPI. The Linux drivers interface is not known for its stability, and constant drift there in both formal spelling of interfaces and in semantic requires to have all drivers using the wrapper to be at the same upstream version. This objection is not specific to drm code, but so far we only speek about infiniband and drm. 2. This cause is probably very drm-specific. Comparing with infiniband, drm integration with very core of the FreeBSD kernel is quite significant. In particular, its coupling with the VM subsystem has no prior examples among the drivers, even if you consider the removed zero-copy sockets code or any driver providing dev_mmap cdevsw method. Even NVidia blob did not got that level of integration with the VM, but probably would benefit from it. The only remotely close example is vbox, but I usually avoid reading that code. I mean things like managed fictitious pages, new device pager page fault handler, or CPU cache management. All of this is used both by i195/GEM and TTM. With the use of the listed facilities, ported driver code 'feels' like FreeBSD code, not Linux code. Mix of the Linux KPI-compatible wrappers for shallow facilities, and native interfaces for anything more involved, makes the code which is hard to understand for either FreeBSD or Linux developers. This was the reason why I selected the 'no wrappers' approach for initial port of GEM, and continue to prefer it now. --+9Mf+ORMRPqeJE8p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUDYdMAAoJEJDCuSvBvK1BcoMQAJnXWaT2Xw+gwva01fnhiTTS u9tGgI7M9RvVVOFSlRZnXYMeFTnqsWaYiGdtjHys6jXKN9BV+AuvPtKKrDnBlgjY f8d/XI49oFJyXNbnda/6g2ttMVi9bmssuM9mHg9CWP2iZEr78PmIFbpiz6B9U4Rd jIDCYwDvnHHSJBCnxTqzNeGST3rEhi6vARtowOn1YgMPBtRI2Qjf0SF3IvmEdIua d6VGfzt1DY9Q9xAtqNv6YVKsCfauCv98f47Ar52tu3tM9VoHeSXQGiu0wP3iUyKd vaVwX9gBH3591hbpUI8xvvZxuwYSn0TsdnGk4Y2GzQfXwlO0xiopwSDAPNOcrD2m p3q32rOxeUj8WLNEz9qask7keVlJC9aQpW5AAYhjsDvPJAJjsutr1sYCjmJIyG66 aA3FABC2ECg2Qsx7O+OM1TDXAwAgHkh1FJUkxEDD/XV1Hl/AI27T7mzYOu+JAWjL 9qRntkcJZNqOj23gpGtFcOpP2lpcWAr/jB1oPo4SbyDyzismFaJD/t20Lxir6iuV pHg0Yt/zLLb0MkmV2q2iEvPal5MNdJAlqFREGfoUzbeTk8hVx4IxO1oTty+mVjO0 d6gAp34RsKfvJj8prUF5E5NhRew0GN2CHyMIpx8GNah0kRKtAcDkZ4hxM8r+up8g zbhihsgXocJHayBqs+Zu =vMSn -----END PGP SIGNATURE----- --+9Mf+ORMRPqeJE8p--