[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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?


 \ /
  Last update: 2015-03-05 16:01    [W:0.091 / U:1.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site