linux-kernel - Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 Mar 2015 09:35:58 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Emil Medve <Emilian.Medve@...escale.com>,
	linuxppc-dev@...ts.ozlabs.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
CC:	Igal Liberman <Igal.Liberman@...escale.com>
Subject: Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

Hi Emil,

On 03/05/15 08:48, Emil Medve wrote:

> The intent is to upstream the entire suite of the DPAA drivers. All the
> drivers are still WIP, but B/QMan have been already presented to the
> upstream community and this is the first attempt to publish (some low
> level code of) the FMan driver. As we go through our internal checklist
> and in the same time address community feedback we'll soon get the
> drivers to be acceptable for the upstream trees
>
> The first version of the actual Ethernet driver will follow imminently
>
> SDK enablement is a side-effect
>

Meaning? Let me ask the question differently:
Do i need your sdk to use the features exposed or can i use something
like tc to set up the deficit rr or wred or the exposed classifiers
and associated actions?
Would your sdk (via user space direct programming) benefit because you
have pushed these pieces into the kernel?

>> How are you planning to
>> add support for your classifiers, queue schedulers etc?
>
> Yes
>

Yes as in these will be available via linux kernel or via your sdk?

>> Is that a patch
>> on top of this or it is something that sits on user space?
>
> Both. Full DPAA/Ethernet enablement will be present in the kernel. We
> also have support for user-space based approach. I'm unsure where/when
> we might publish that. Of course the SDK is always a place you can turn
> to for all the code we have (in whatever state it might be)
>

the sdk is open source?

cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/