On Mon, Jun 12, 2017 at 7:17 PM, Jason Gunthorpe
wrote:
> On Sat, Jun 10, 2017 at 02:11:13PM +, Majd Dibbiny wrote:
>
>> >> This is especially true for mlx nics as there are many raw packet
>> >> bypass mechanisms available to userspace.
>
>> All of the Raw packet bypass mechanisms are restric
On Sat, Jun 10, 2017 at 02:11:13PM +, Majd Dibbiny wrote:
> >> This is especially true for mlx nics as there are many raw packet
> >> bypass mechanisms available to userspace.
> All of the Raw packet bypass mechanisms are restricted to
> CAP_NET_RAW, and thus malicious users can't simply open
On Sun, Jun 11, 2017 at 05:59:04AM +, Ilan Tayari wrote:
> > This is especially true for mlx nics as there are many raw packet
> > bypass mechanisms available to userspace.
>
> The device uses internal signaling that ensures that no entity other
> than the mlx5 driver can talk over the FPGA ch
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> > > This keep getting more ugly :(
> > >
> > > What about security? What if u
> On Jun 10, 2017, at 1:24 AM, Doug Ledford wrote:
>
>> On Wed, 2017-06-07 at 13:21 -0600, Jason Gunthorpe wrote:
>>> On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
>>>
>>> No !!
>>> I am just showing you that the ib_core eventually will end up
>>> calling
>>> mlx5_core to cre
On Wed, 2017-06-07 at 13:21 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
> >
> > No !!
> > I am just showing you that the ib_core eventually will end up
> > calling
> > mlx5_core to create a QP.
> > so mlx5_core can create the QP it self since it
On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
> On Wed, Jun 7, 2017 at 6:48 PM, Jason Gunthorpe
> wrote:
> > On Wed, Jun 07, 2017 at 07:16:42AM +0300, Saeed Mahameed wrote:
> >> On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe
> >> wrote:
> >> > On Tue, Jun 06, 2017 at 06:52:15AM
On Wed, Jun 7, 2017 at 6:48 PM, Jason Gunthorpe
wrote:
> On Wed, Jun 07, 2017 at 07:16:42AM +0300, Saeed Mahameed wrote:
>> On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe
>> wrote:
>> > On Tue, Jun 06, 2017 at 06:52:15AM +, Ilan Tayari wrote:
>> >
>> >> So neither the host stack nor the netw
On Wed, Jun 07, 2017 at 07:16:42AM +0300, Saeed Mahameed wrote:
> On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe
> wrote:
> > On Tue, Jun 06, 2017 at 06:52:15AM +, Ilan Tayari wrote:
> >
> >> So neither the host stack nor the network are aware of them.
> >> They exist momentarily only on the
On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe
wrote:
> On Tue, Jun 06, 2017 at 06:52:15AM +, Ilan Tayari wrote:
>
>> So neither the host stack nor the network are aware of them.
>> They exist momentarily only on the internal traces on the board and not
>> anywhere else.
>
> Is that really tr
On Wed, Jun 7, 2017 at 1:44 AM, Alexei Starovoitov
wrote:
> On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
>> From: Alexei Starovoitov
>> Date: Tue, 6 Jun 2017 11:55:33 -0700
>>
>> > If in the future mlx will make it into the nic in a way that
>> > encryption shares all memory mana
On Tue, Jun 06, 2017 at 03:44:53PM -0700, Alexei Starovoitov wrote:
> On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
> > From: Alexei Starovoitov
> > Date: Tue, 6 Jun 2017 11:55:33 -0700
> >
> > > If in the future mlx will make it into the nic in a way that
> > > encryption shares
On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Tue, 6 Jun 2017 11:55:33 -0700
>
> > If in the future mlx will make it into the nic in a way that
> > encryption shares all memory management logic and there is no fpga
> > at all then it indeed will
From: Alexei Starovoitov
Date: Tue, 6 Jun 2017 11:55:33 -0700
> If in the future mlx will make it into the nic in a way that
> encryption shares all memory management logic and there is no fpga
> at all then it indeed will be similar to tc offload. Right now it's
> not and needs different sw arch
On Tue, Jun 06, 2017 at 02:38:24PM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Tue, 6 Jun 2017 11:34:59 -0700
>
> > fpga is a separate device with its own phy and mac layers, its
> > own queues, packet parsing and rdma logic.
>
> Because that's how they bolted it onto the ASIC
From: Alexei Starovoitov
Date: Tue, 6 Jun 2017 11:34:59 -0700
> fpga is a separate device with its own phy and mac layers, its
> own queues, packet parsing and rdma logic.
Because that's how they bolted it onto the ASIC in current
implementation, it might not always be that way and be fully
inte
On Tue, Jun 06, 2017 at 01:47:26PM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Tue, 6 Jun 2017 10:42:35 -0700
>
> > so it's like rdma, but without using kernel rdma stack?
>
> No sockets here, just transformation rules. It's like offloading
> a complex TC rule to hardware vers
From: Alexei Starovoitov
Date: Tue, 6 Jun 2017 10:42:35 -0700
> so it's like rdma, but without using kernel rdma stack?
No sockets here, just transformation rules. It's like offloading
a complex TC rule to hardware version of that transformation.
Yes, there is state, but I argue that it is no
On Tue, Jun 06, 2017 at 10:17:09AM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 06, 2017 at 06:52:15AM +, Ilan Tayari wrote:
>
> > So neither the host stack nor the network are aware of them.
> > They exist momentarily only on the internal traces on the board and not
> > anywhere else.
>
> Is
On Tue, Jun 06, 2017 at 06:52:15AM +, Ilan Tayari wrote:
> So neither the host stack nor the network are aware of them.
> They exist momentarily only on the internal traces on the board and not
> anywhere else.
Is that really true? If you are creating rocee QPs' then the RDMA
stack sees this
From: Ilan Tayari
Date: Tue, 6 Jun 2017 06:52:15 +
> The fact that we configure the FPGA using special inband packets isn't
> changing anything. IMO, it might have been any other bus on the card,
> standard or proprietary, and the arguments for how to design the driver
> would stay the same.
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Sun, Jun 04, 2017 at 07:51:24AM +, Ilan Tayari wrote:
> > > From: Jason G
On Sun, Jun 04, 2017 at 07:51:24AM +, Ilan Tayari wrote:
> > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
> >
> > On Mon, May 29, 2017 at 04:09:06PM +, Ilan Tayari wrote
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Mon, May 29, 2017 at 04:09:06PM +, Ilan Tayari wrote:
>
> > > For IPSec, this is alrea
On Fri, 2017-06-02 at 16:31 -0400, Jes Sorensen wrote:
>
> > It is already modular like that. See CONFIG_MLX5_FPGA.
>
> [jes@xpeas netdev.git]$ grep CONFIG_MLX5_FPGA
> drivers/net/ethernet/mellanox/mlx5/core/*
> [jes@xpeas netdev.git]$
>
> Which git tree am I supposed to look at?
net-next
--
On 05/28/2017 03:24 AM, Ilan Tayari wrote:
-Original Message-
From: Jes Sorensen [mailto:jsoren...@fb.com]
On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
Hi Jes,
No, It is clearly stat
On Mon, May 29, 2017 at 04:09:06PM +, Ilan Tayari wrote:
> > For IPSec, this is already in the kernel.
> > See this patchset:
> > http://www.mail-archive.com/netdev@vger.kernel.org/msg162876.html
>
> Sorry, I pointed at the RFC by mistake.
>
> This is the relevant pull request:
> https://pat
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic suppor
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Mon, May 29, 2017 at 03:58:33PM +, Ilan Tayari wrote:
> > > From: Jason G
On Mon, May 29, 2017 at 03:58:33PM +, Ilan Tayari wrote:
> > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
> >
> > On Sun, May 28, 2017 at 07:22:27AM +, Ilan Tayari w
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Sun, May 28, 2017 at 07:22:27AM +, Ilan Tayari wrote:
>
> > This is neither PCI-bar map
On Sun, May 28, 2017 at 07:22:27AM +, Ilan Tayari wrote:
> This is neither PCI-bar mapped, nor mailbox command.
> The FPGA is indeed a bump-on-the-wire.
> (It has I2C to the CX4 chip, but that is for debug purposes, and too slow
> to perform real programming)
Wait.. So if it truely has nothin
On Fri, May 26, 2017 at 8:56 PM, Alexei Starovoitov
wrote:
> On Fri, May 26, 2017 at 11:59:26AM +0300, Saeed Mahameed wrote:
>> But i agree with you some serious API brainstorming should be
>> considered, but not at this stage, this patch only tells the ConnectX card
>> (if you have FPGA, please
> -Original Message-
> From: Jes Sorensen [mailto:jsoren...@fb.com]
>
> On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
> > On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
> >> On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
> > Hi Jes,
> >
> > No, It is clearly stated in the commit mes
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
>
> On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote:
>
> > > for that feature which is the originating place, before defining
> > > APIs/infrastructures,
> > > until the feature is com
On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
Hi Jes,
No, It is clearly stated in the commit message :
"The FPGA is a bump-on-the-wire and thus affects operation of
the mlx5_core driver on the
On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote:
> > for that feature which is the originating place, before defining
> > APIs/infrastructures,
> > until the feature is complete and every body is happy about it.
>
> There is driver/fpga to manage fpga, but mlx fpga+nic combo
>
On Fri, May 26, 2017 at 11:59:26AM +0300, Saeed Mahameed wrote:
>
> And for FPGA support, we did it correctly this time, all the new code
> is under mlx5/core/fgpa ..
s/correctly/incorrectly/ ?
> Well, this is a well known dilemma, if one has a new feature and has no
> sandbox
> area to put it
From: Alexei Starovoitov
Date: Thu, 25 May 2017 21:40:59 -0700
> On Fri, May 26, 2017 at 12:13:27AM -0400, David Miller wrote:
>> From: Alexei Starovoitov
>> Date: Thu, 25 May 2017 20:58:32 -0700
>>
>> > Dave, please revert this Innova fpga stuff.
>> > I think you pushed it by accident, since i
On Fri, May 26, 2017 at 6:07 AM, Alexei Starovoitov
wrote:
> On Thu, May 25, 2017 at 05:20:04AM +, Ilan Tayari wrote:
>>
>> If you do want this, then splitting some of the logic to a
>> separate kernel object will not gain anything useful (logic would stay
>> the same), and just pollute the ex
On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
> On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
>>
>> On Thu, May 25, 2017 at 8:20 AM, Ilan Tayari wrote:
-Original Message-
Can you put it into different driver? Dumping everything into by far
the biggest nic drive
On Fri, May 26, 2017 at 12:13:27AM -0400, David Miller wrote:
> From: Alexei Starovoitov
> Date: Thu, 25 May 2017 20:58:32 -0700
>
> > Dave, please revert this Innova fpga stuff.
> > I think you pushed it by accident, since it was mixed with
> > other valid changes.
> > The discussion didn't conc
From: Alexei Starovoitov
Date: Thu, 25 May 2017 20:58:32 -0700
> Dave, please revert this Innova fpga stuff.
> I think you pushed it by accident, since it was mixed with
> other valid changes.
> The discussion didn't conclude.
> Myself and Jes are clearly against such changes.
> It definitely nee
On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote:
> From: Ilan Tayari
>
> Mellanox Innova is a NIC with ConnectX and an FPGA on the same
> board. The FPGA is a bump-on-the-wire and thus affects operation of
> the mlx5_core driver on the ConnectX ASIC.
>
> Add basic support for Inno
On Thu, May 25, 2017 at 05:20:04AM +, Ilan Tayari wrote:
>
> If you do want this, then splitting some of the logic to a
> separate kernel object will not gain anything useful (logic would stay
> the same), and just pollute the exported symbol table and open up the door
> for issues of inter-mo
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 8:20 AM, Ilan Tayari wrote:
-Original Message-
Can you put it into different driver? Dumping everything into by far
the biggest nic driver already is already huge headache in terms on
maintainability, debugging and ba
On Thu, May 25, 2017 at 8:20 AM, Ilan Tayari wrote:
>> -Original Message-
>> From: Alexei Starovoitov [mailto:alexei.starovoi...@gmail.com]
>>
>> On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote:
>> > From: Ilan Tayari
>> >
>> > Mellanox Innova is a NIC with ConnectX and an
> -Original Message-
> From: Alexei Starovoitov [mailto:alexei.starovoi...@gmail.com]
>
> On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote:
> > From: Ilan Tayari
> >
> > Mellanox Innova is a NIC with ConnectX and an FPGA on the same
> > board. The FPGA is a bump-on-the-wire
On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote:
> From: Ilan Tayari
>
> Mellanox Innova is a NIC with ConnectX and an FPGA on the same
> board. The FPGA is a bump-on-the-wire and thus affects operation of
> the mlx5_core driver on the ConnectX ASIC.
>
> Add basic support for Inno
From: Ilan Tayari
Mellanox Innova is a NIC with ConnectX and an FPGA on the same
board. The FPGA is a bump-on-the-wire and thus affects operation of
the mlx5_core driver on the ConnectX ASIC.
Add basic support for Innova in mlx5_core.
This allows using the Innova card as a regular NIC, by detec
50 matches
Mail list logo
