DPDK patches and discussions
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagi@grimberg.me>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "Shahaf Shuler" <shahafs@mellanox.com>,
	"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
	"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: Thu, 27 Jul 2017 13:48:30 +0300	[thread overview]
Message-ID: <299ae471-67a5-4b8d-6596-1cb996006d90@grimberg.me> (raw)
In-Reply-To: <20170724134447.GB2848@bricha3-MOBL3.ger.corp.intel.com>


>> 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)?
>>
> Would using VFIO (and the IOMMU) not allow us to provide an equivalent
> level of security to what is provided by the current scheme?

mlx5 does not take over the device with vfio, it simply asks the
kernel to setup resources for it and sets a mac steering rule to
direct traffic to its own rings. Also, I'm not aware of any way to
enforce iommu is enabled.

> From what I
> see on-list there are a few folks already looking into that area, and
> taking advantage of the IOMMU should improve security of all devices in
> DPDK.

I agree that this can be improved in dpdk, I was simply arguing that
mlx5 guarantees alone are not very valuable, especially considering
the work-arounds taken in mlx5 to achieve it.

mlx5 can be converted to take over the device with vfio and simply not
deal with memory registration aspects, but that is really up to mlx5
maintainers.

      reply	other threads:[~2017-07-27 10:48 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
2017-07-24 13:44                 ` Bruce Richardson
2017-07-27 10:48                   ` Sagi Grimberg [this message]

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=299ae471-67a5-4b8d-6596-1cb996006d90@grimberg.me \
    --to=sagi@grimberg.me \
    --cc=bruce.richardson@intel.com \
    --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).