From: Pavel Odintsov <pavel.odintsov@gmail.com>
To: Olga Shern <olgas@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox ConnectX-3 devices
Date: Tue, 7 Jul 2015 10:02:24 +0300 [thread overview]
Message-ID: <CALgsdbfVYAhFXRDk+_TVZRj_S1FRNCfhWnFrqBbEkNp1+2YsZQ@mail.gmail.com> (raw)
In-Reply-To: <AM2PR05MB0995248BE5FD8202727A4BDED3920@AM2PR05MB0995.eurprd05.prod.outlook.com>
Hello!
Sorry for off topic. But this question is very important for me.
Olga, could I achieve line rate with Mellanox Cards with 64b packets for 40GE?
On Tue, Jul 7, 2015 at 9:50 AM, Olga Shern <olgas@mellanox.com> wrote:
> Hi Keunhong,
>
> I disagree with you regarding the performance of ConnectX-3 PMD driver based on verbs. We get line rate of 40G link with message size smaller than 512B.
> In MLNX_OFED 3.0 we have presented a new verbs, called accelerated verbs, these verbs improves by more than 100% the performance of RAW QP for DPDK. The PMD changes based on this new infrastructure have been submitted to this list and are part of DPDK 2.1 release.
> Our approach is to improve performance of userspace verbs then to maintain a huge amount of code that you have submitted.
>
> Another advantage to use userspace verbs API is that you have so called bi-furcated driver by design. Kernel driver can work side by side with DPDK PMD , if needed, and there is no security issues with this model.
>
> Best Regards,
> Olga
>
>
> ________________________________________________________________
> Olga Shern
> Sr. Manager, Acceleration libraries team (Accelio, DPDK, VMA)
> Mellanox Technologies, Raanana Israel
>
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keunhong Lee
> Sent: Monday, July 06, 2015 8:56 PM
> To: Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox ConnectX-3 devices
>
> We found that optimizing fragmentation configuration of mlx4 driver performs as fast as native PMD.
> I think we have to re-consider using native driver rather than ib driver.
>
> Keunhong.
>
> 2015-07-07 1:14 GMT+09:00 Thomas Monjalon <thomas.monjalon@6wind.com>:
>
>> 2015-07-07 00:57, Keunhong Lee:
>> > Answer 1. UIO based driver is faster then ib based driver.
>> > It can saturate 40G link with MTU sized packets using a single
>> > thread
>> while
>> > ib wrapper cannot.
>>
>> OK, interesting. Do you have numbers and details about your
>> testbed/scenario?
>>
>> > Answer 2. Sorry, I missed that. I'll make a new patch email with my
>> > real name.
>> >
>> > Question 1. Is it OK if I separate GPL-based and BSD-based codes
>> > into separated patches?
>> > mlx4 kernel driver itself is dual licenses, so I think they are
>> considered
>> > as BSD in my source code.
>> > The only source code under GPL is bitmap, integer logarithm, and
>> red-black
>> > tree contained in mlnx_uio/kernel directory.
>>
>> These parts will be built in the user-space driver library, right?
>> It would change the license, which is not desirable.
>>
>> Technically, your approach may be interesting.
>> But from a maintenance point of view, this huge codebase may be a
>> nightmare.
>>
>>
>> > 2015-07-06 23:17 GMT+09:00 Thomas Monjalon <thomas.monjalon@6wind.com>:
>> >
>> > > 2015-07-06 22:28, leeopop:
>> > > > This is a native UIO-based PMD for Mellanox ConnectX-3 devices.
>> > > > It uses a persistent memory library in order to provide a
>> > > > persistent scartch area for the mlx4 HCA driver.
>> > >
>> > > What is the benefit of this UIO approach compared to the OFED
>> > > based
>> driver?
>> > >
>> > > > We release the driver itself under BSD license, but to use it
>> > > > for commercial products, you may have to re-implement the
>> > > > separated GPL sources.
>> > >
>> > > The GPL sources are not really separated.
>> > > The DPDK libraries must be BSD-licensed.
>> > >
>> > > > The GPL affected source codes reside in the mlnx_uio/kernel
>> directory.
>> > >
>> > > It seems that a large part of the GPL driver was also copied in
>> > > mlnx_uio/mlnx/.
>> > >
>> > > Given that you are dropping a huge GPL codebase (whose you don't
>> > > own
>> the
>> > > copyright) in a BSD library, and that you didn't give your real
>> > > name in the signed-off line, it is NACK.
>>
>>
>>
>>
--
Sincerely yours, Pavel Odintsov
next prev parent reply other threads:[~2015-07-07 7:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 13:28 leeopop
2015-07-06 13:28 ` [dpdk-dev] [PATCH 1/2] eal/persistent: new library to hold memory region after program exit leeopop
2015-07-06 14:34 ` Avi Kivity
2015-07-06 14:41 ` Thomas Monjalon
2015-07-06 19:19 ` Stephen Hemminger
2015-07-06 13:28 ` [dpdk-dev] [PATCH 2/2] mlnx_uio: new poll mode driver leeopop
2015-07-06 14:17 ` [dpdk-dev] [PATCH 0/2] Native uio-based PMD for Mellanox ConnectX-3 devices Thomas Monjalon
2015-07-06 15:57 ` Keunhong Lee
2015-07-06 16:14 ` Thomas Monjalon
2015-07-06 17:55 ` Keunhong Lee
2015-07-07 6:50 ` Olga Shern
2015-07-07 7:02 ` Pavel Odintsov [this message]
2015-07-07 9:18 ` Olga Shern
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=CALgsdbfVYAhFXRDk+_TVZRj_S1FRNCfhWnFrqBbEkNp1+2YsZQ@mail.gmail.com \
--to=pavel.odintsov@gmail.com \
--cc=dev@dpdk.org \
--cc=olgas@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).