From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40F6BC433E0 for ; Wed, 3 Feb 2021 11:09:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C96F364E93 for ; Wed, 3 Feb 2021 11:09:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C96F364E93 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 162076EA5D; Wed, 3 Feb 2021 11:09:37 +0000 (UTC) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7EE476EA5C for ; Wed, 3 Feb 2021 11:09:36 +0000 (UTC) Received: by mail-wr1-x431.google.com with SMTP id a1so23730060wrq.6 for ; Wed, 03 Feb 2021 03:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=10v1VhHSAkUfosKyz8E/GXqf1Nzg9103R9baLtggV6c=; b=AwADaWJ4LwJCoyZjbksaAIXa2APpKqAzdcH9SXnJSG7fszSPLuUH+3Bwq8LRRDPDdi NoWIXSFbFk7LIjysbkr0z+9qT5D6IV+LPHIDP1dNAXkIXUoE8fy0uJRszcDfXUx0bqw7 A7GDs34BM4mVn+70Za7HOYwh3WFfPNv53flts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=10v1VhHSAkUfosKyz8E/GXqf1Nzg9103R9baLtggV6c=; b=qEM+ClZ7xLvgtpuYR1eCGcvWGwm986SlaUaR55b6BTmKR4I6QmIdJnx/aN+IId1PN4 i+gKaKG7P4x9jkMV2id0qCrkBUw7Zpc0cZBg2BGU8Srwo7UckiExXgTCYOGZvpVw+0pD IouqiFRzeLzpel/pzMR8IKCNwBzZUZXtnAfZeg8Rp+H+Mro1+zGkUIFn9aZpt8cWb0Pv yhH18R1qArw06KzndDFEx65kAh0ilsHuwvuUUxRFPhgqldzr9V3KK/Ry/tAzIInZ/Zdu YRKJ2Eqj31c78XKvkG/G0UMqHvRP1VtllveEMUeE/SNkEOvCXDPjyqdQd2hRuWDTkxBQ nXCA== X-Gm-Message-State: AOAM5328J+RirnjmuREnAq7uuKqNTC11yz5aROyMWs4BmCgxQAFGItdv Uvq5DoWRM+hfcO+4cSzOpu3ZSA== X-Google-Smtp-Source: ABdhPJz/Tt+QvRistfYVb5CQI5w5vU2oPDBqvoYzreN0pUZNDkogq1vrI5kxcwA1KSZxNTuzut/k+A== X-Received: by 2002:a5d:6351:: with SMTP id b17mr2881295wrw.410.1612350575262; Wed, 03 Feb 2021 03:09:35 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id z15sm2969771wrs.25.2021.02.03.03.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 03:09:34 -0800 (PST) Date: Wed, 3 Feb 2021 12:09:32 +0100 From: Daniel Vetter To: Kenny Ho Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL Message-ID: References: <20201103053244.khibmr66p7lhv7ge@ast-mbp.dhcp.thefacebook.com> <20201103210418.q7hddyl7rvdplike@ast-mbp.dhcp.thefacebook.com> <20201103232805.6uq4zg3gdvw2iiki@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Song Liu , Andrii Nakryiko , DRI Development , Daniel Borkmann , Kenny Ho , "open list:CONTROL GROUP \(CGROUP\)" , Brian Welty , John Fastabend , Alexei Starovoitov , amd-gfx list , Martin KaFai Lau , Linux-Fsdevel , Alexander Viro , Network Development , KP Singh , Yonghong Song , bpf , Alexei Starovoitov , Alex Deucher Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Feb 01, 2021 at 11:51:07AM -0500, Kenny Ho wrote: > [Resent in plain text.] > > On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter wrote: > > - there's been a pile of cgroups proposal to manage gpus at the drm > > subsystem level, some by Kenny, and frankly this at least looks a bit > > like a quick hack to sidestep the consensus process for that. > No Daniel, this is quick *draft* to get a conversation going. Bpf was > actually a path suggested by Tejun back in 2018 so I think you are > mischaracterizing this quite a bit. > > "2018-11-20 Kenny Ho: > To put the questions in more concrete terms, let say a user wants to > expose certain part of a gpu to a particular cgroup similar to the > way selective cpu cores are exposed to a cgroup via cpuset, how > should we go about enabling such functionality? > > 2018-11-20 Tejun Heo: > Do what the intel driver or bpf is doing? It's not difficult to hook > into cgroup for identification purposes." Yeah, but if you go full amd specific for this, you might as well have a specific BPF hook which is called in amdgpu/kfd and returns you the CU mask for a given cgroups (and figures that out however it pleases). Not a generic framework which lets you build pretty much any possible cgroups controller for anything else using BPF. Trying to filter anything at the generic ioctl just doesn't feel like a great idea that's long term maintainable. E.g. what happens if there's new uapi for command submission/context creation and now your bpf filter isn't catching all access anymore? If it's an explicit hook that explicitly computes the CU mask, then we can add more checks as needed. With ioctl that's impossible. Plus I'm also not sure whether that's really a good idea still, since if cloud companies have to built their own bespoke container stuff for every gpu vendor, that's quite a bad platform we're building. And "I'd like to make sure my gpu is used fairly among multiple tenents" really isn't a use-case that's specific to amd. If this would be something very hw specific like cache assignment and quality of service stuff or things like that, then vendor specific imo makes sense. But for CU masks essentially we're cutting the compute resources up in some way, and I kinda expect everyone with a gpu who cares about isolating workloads with cgroups wants to do that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel