From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id DA9A123A for ; Sun, 23 Jul 2017 11:03:47 +0200 (CEST) Received: by mail-wr0-f180.google.com with SMTP id 33so39174445wrz.4 for ; Sun, 23 Jul 2017 02:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+bEaqUbyHCCMVvbb3J7L3uhbDzV/+7FyajLeI+n7mOA=; b=U3YULMvGtEsWmeimu+QpLMwPIXqB406NREtp9gEP9NEmsVVgzpIAJNKYuMmNFETE0L ONDHiO+fb0jM8hNxrjkVePHwdAwaBdnqNqDp4o+GFOjENPxa114f9B36qvc2rrgUT5Ci FTrTxKkbUJBFCQ9RM5Wu4wd7ApyPUkY3vc4DgM+REJ0Lt+70mpsMGvh/UShDKH46mQ1a sUWT7B7cAJLtwsDqvvDcM5B+Res71BBXUalwetP1AX7EFfGj7SGW/Aah96jwoz6vg/tR BhrL+fCxXYEs8mGC0MOAZf8iFAh0aOXhwhKrK3BuGMF39s+vyRWJfI0Xkwbc1hw5IVm3 95lQ== X-Gm-Message-State: AIVw112vv7ElJeg/hwtAOGnOd05EfL+N7OdNjISH6mBJUOL/RgQVlKna CM0eSkrFnuFmrg== X-Received: by 10.223.165.71 with SMTP id j7mr4190806wrb.147.1500800627218; Sun, 23 Jul 2017 02:03:47 -0700 (PDT) Received: from [192.168.64.116] (bzq-82-81-101-184.red.bezeqint.net. [82.81.101.184]) by smtp.gmail.com with ESMTPSA id v203sm6017868wmd.2.2017.07.23.02.03.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 02:03:43 -0700 (PDT) To: Shahaf Shuler , =?UTF-8?Q?N=c3=a9lio_Laranjeiro?= Cc: "dev@dpdk.org" , Yongseok Koh , Roy Shterman , Alexander Solganik , Leon Romanovsky References: <75d08202-1882-7660-924c-b6dbb4455b88@grimberg.me> <20170717210222.j4dwxiujqdlqhlp2@shalom> <85c0b1d9-bbf3-c6ab-727f-f508c5e5f584@grimberg.me> <20170720135548.qlkjnmzthd2vep5e@shalom> <957f84fe-199a-e016-c21c-ab54a732e561@grimberg.me> <67476089-ba6e-905c-0fdd-3a1551de97d4@grimberg.me> From: Sagi Grimberg Message-ID: <0874aa20-27c1-190e-ebba-7fa075eaac7a@grimberg.me> Date: Sun, 23 Jul 2017 12:03:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Question on mlx5 PMD txq memory registration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 09:03:48 -0000 >> I don't understand the security argument. Its completely private to the >> driver. anything under librte is equivalent to an OS wrt networking, so I fail to >> see what is the security feature your talking about. > > You are correct that as a root you are able to do whatever you want on the server. > The security I refer to is to protect against badly written code. > > The fact the PMD only registers the mempools, and use the device engine to translate the VA, provide some protection. > For example, one DPDK process will not be able to access the memory of other DPDK process *by mistake*. Well, this is a fair argument, but without a *complete* solution for all of dpdk peripherals, it has very little merit (if at all). A badly written code can just as easily crash a server by passing a mbuf to a crypto device or another network device that co-exists with mlx5. So, while I understand the argument, I think its value is not worth the hassle that mlx5_pmd needs to take to achieve it. Did this come from a real requirement (from a real implementation)? > I am not saying using the reserved lkey is not a good suggestion, and we plan to test its value. > All I am saying is there are maybe other option to provide the same performance with the extra protection mentioned above. > One of them can be to use indirect keys. One indirect key to represent 64b memory area, and other regular keys for the hugepages. > The rest of the memory area can be filled with keys pointing to /dev/null. If I understand what you are suggesting, this would trigger out-of-order transfers on an indirect memory key just about always (each transfer can originate from a different hugepage and SGL resolution alone will require a walk on the memory key context SGL list). I'm afraid this would introduce a very bad performance scaling due to the fact that a SGL context (klm) will need to be fetched from the ICM for essentially every send operation. Having said that, its just my 2 cents, if your solution works then I don't really care. You are the one testing it... >>> The fact running under root doesn't mean you have privileges to access >> every physical page on the server (even if you try very hard to be aware). >> >> But dpdk core mbufs structs are built this way. >> >>> The issue here, AFAIU, is performance. >>> We are now looking into ways to provide the same performance as if it was >> only a single lkey, while preserving the security feature. >> >> Hmm, What exactly do you have in mind? >> >> I'm hoping that you are not referring to ODP. If you are, I think that latency >> unpredictability would be a huge non-starter, page-faults are way too >> expensive for dpdk users. > > No ODP :). > As all relevant DPDK memory is on top of hugepages, there is no reason to avoid registration and pinning in advance. Agree.