From: Sagi Grimberg <sagi@grimberg.me>
To: "Shahaf Shuler" <shahafs@mellanox.com>,
"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Yongseok Koh <yskoh@mellanox.com>,
Roy Shterman <roys@lightbitslabs.com>,
Alexander Solganik <sashas@lightbitslabs.com>,
Leon Romanovsky <leonro@mellanox.com>
Subject: Re: [dpdk-dev] Question on mlx5 PMD txq memory registration
Date: Sun, 23 Jul 2017 12:03:41 +0300 [thread overview]
Message-ID: <0874aa20-27c1-190e-ebba-7fa075eaac7a@grimberg.me> (raw)
In-Reply-To: <VI1PR05MB31499E3669E1D55080863BD0C3BA0@VI1PR05MB3149.eurprd05.prod.outlook.com>
>> 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.
next prev parent reply other threads:[~2017-07-23 9:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 13:29 Sagi Grimberg
2017-07-17 21:02 ` Nélio Laranjeiro
2017-07-19 6:21 ` Sagi Grimberg
2017-07-20 13:55 ` Nélio Laranjeiro
2017-07-20 14:06 ` Sagi Grimberg
2017-07-20 15:20 ` Shahaf Shuler
2017-07-20 16:22 ` Sagi Grimberg
2017-07-23 8:17 ` Shahaf Shuler
2017-07-23 9:03 ` Sagi Grimberg [this message]
2017-07-24 13:44 ` Bruce Richardson
2017-07-27 10:48 ` Sagi Grimberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0874aa20-27c1-190e-ebba-7fa075eaac7a@grimberg.me \
--to=sagi@grimberg.me \
--cc=dev@dpdk.org \
--cc=leonro@mellanox.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=roys@lightbitslabs.com \
--cc=sashas@lightbitslabs.com \
--cc=shahafs@mellanox.com \
--cc=yskoh@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).