[dpdk-dev] KNI interface

[dpdk-dev] KNI interface

[Harish Patil]

Hello dpdk-dev,
Went thru’ couple of documentation but not very clear to me. Does using
KNI means handing over all the packets received/transmitted by the poll
mode driver to the linux stack or can it be controlled for the control
packets only ? What is the KNI use-case (besides ethtool) and what are the
best options/choices/strategy to use poll mode driver for data path and
linux for control plane operations ?

Thanks,
Harish






________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: [dpdk-dev] KNI interface

[Bruce Richardson]

On Sat, Jul 19, 2014 at 12:08:35AM +0000, Harish Patil wrote:
> Hello dpdk-dev,
> Went thru’ couple of documentation but not very clear to me. Does using
> KNI means handing over all the packets received/transmitted by the poll
> mode driver to the linux stack or can it be controlled for the control
> packets only ? What is the KNI use-case (besides ethtool) and what are the
> best options/choices/strategy to use poll mode driver for data path and
> linux for control plane operations ?
>

Hi Harish,

the packets to be sent to the kernel through the KNI interface is
entirely under application control, so it can be limited to control path
packets only. Indeed this is the primary expected use case for this
module, as the KNI cannot deal with the kind of data rates that the PMDs
can work with.

Regards,
/Bruce

Re: [dpdk-dev] KNI interface

[Zhou, Danny]

KNI is mainly designed for exception path or control plane packets that need to be pushed
to Linux TCP/IP packets in the kernel. You can push all the packets that DPDK PMD received 
in the user space via KNI to kernel, but majority of them will be dropped for two reasons: 1) skb
allocation/free and memory copy between mbuf and skb 2) slow TCP/IP stack. 
In terms of how to use it, basically it is user responsibility to do simple flow classification using
5-tuple in DPDK application, and push exception packets or control packets to KNI queues, in other
words, to slow path. While DPDK user space still process fast path packets.
	
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harish Patil
> Sent: Saturday, July 19, 2014 8:09 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] KNI interface
> 
> Hello dpdk-dev,
> Went thru’ couple of documentation but not very clear to me. Does using
> KNI means handing over all the packets received/transmitted by the poll
> mode driver to the linux stack or can it be controlled for the control
> packets only ? What is the KNI use-case (besides ethtool) and what are the
> best options/choices/strategy to use poll mode driver for data path and
> linux for control plane operations ?
> 
> Thanks,
> Harish
> 
> 
> 
> 
> 
> 
> ________________________________
> 
> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be
> confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this
> transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: [dpdk-dev] KNI interface

[Harish Patil]

>KNI is mainly designed for exception path or control plane packets that
>need to be pushed
>to Linux TCP/IP packets in the kernel. You can push all the packets that
>DPDK PMD received
>in the user space via KNI to kernel, but majority of them will be dropped
>for two reasons: 1) skb
>allocation/free and memory copy between mbuf and skb 2) slow TCP/IP
>stack.
>In terms of how to use it, basically it is user responsibility to do
>simple flow classification using
>5-tuple in DPDK application, and push exception packets or control
>packets to KNI queues, in other
>words, to slow path. While DPDK user space still process fast path
>packets.

Thanks for the clarification, Bruce/Danny.

Few follow-on questions:

i) Does the generic 5-tuple flow classification that the DPDK provides
would cover all possible packet types (e.g. Q-Q/tunneled/vxlan etc)?.
Manual packet parsing by the poll mode driver would be a daunting task by
itself.

ii) How would the forwarding/routing changes in the kernel pushed to (or
synchronized with) the DPDK L2/L3 application?

iii) Can we just live with [base DPDK + linux TCP/IP stack], without
third-party modules, to achieve full networking stack functionality at
least in a non-virtualized environment ?


>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harish Patil
>> Sent: Saturday, July 19, 2014 8:09 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] KNI interface
>>
>> Hello dpdk-dev,
>> Went thru’ couple of documentation but not very clear to me. Does using
>> KNI means handing over all the packets received/transmitted by the poll
>> mode driver to the linux stack or can it be controlled for the control
>> packets only ? What is the KNI use-case (besides ethtool) and what are
>>the
>> best options/choices/strategy to use poll mode driver for data path and
>> linux for control plane operations ?
>>
>> Thanks,
>> Harish
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> This message and any attached documents contain information from QLogic
>>Corporation or its wholly-owned subsidiaries that may be
>> confidential. If you are not the intended recipient, you may not read,
>>copy, distribute, or use this information. If you have received this
>> transmission in error, please notify the sender immediately by reply
>>e-mail and then delete this message.
>



________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: [dpdk-dev] KNI interface

[Zhou, Danny]

> >KNI is mainly designed for exception path or control plane packets that
> >need to be pushed
> >to Linux TCP/IP packets in the kernel. You can push all the packets that
> >DPDK PMD received
> >in the user space via KNI to kernel, but majority of them will be dropped
> >for two reasons: 1) skb
> >allocation/free and memory copy between mbuf and skb 2) slow TCP/IP
> >stack.
> >In terms of how to use it, basically it is user responsibility to do
> >simple flow classification using
> >5-tuple in DPDK application, and push exception packets or control
> >packets to KNI queues, in other
> >words, to slow path. While DPDK user space still process fast path
> >packets.
> 
> Thanks for the clarification, Bruce/Danny.
> 
> Few follow-on questions:
> 
> i) Does the generic 5-tuple flow classification that the DPDK provides
> would cover all possible packet types (e.g. Q-Q/tunneled/vxlan etc)?.
> Manual packet parsing by the poll mode driver would be a daunting task by
> itself.

No, you have to parse the packet yourself to determine the packet type.
DPDK is library rather than an application that allows you develop your own
packet processing application. In general, switch silicon or FPAG based smart
NIC could offload all or part of packet parsing works, but for generic high-volume
NIC without a parser, you have to parse them in software.

> 
> ii) How would the forwarding/routing changes in the kernel pushed to (or
> synchronized with) the DPDK L2/L3 application?
> 

Typically, DPDK just forward them to the NIC, as what KNI sample application does.

> iii) Can we just live with [base DPDK + linux TCP/IP stack], without
> third-party modules, to achieve full networking stack functionality at
> least in a non-virtualized environment ?
> 

DPDK is primarily in user space, except for KNI sitting in the kernel and bridges user space 
DPDK and kernel space TCP/IP stack via huge page based software queues. There is a 
bifurcated driver prototype under development might fit whatever you requirement, or you can
integrate commercial or open-sourced user space TCP/IP stack.

> 
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harish Patil
> >> Sent: Saturday, July 19, 2014 8:09 AM
> >> To: dev@dpdk.org
> >> Subject: [dpdk-dev] KNI interface
> >>
> >> Hello dpdk-dev,
> >> Went thru’ couple of documentation but not very clear to me. Does using
> >> KNI means handing over all the packets received/transmitted by the poll
> >> mode driver to the linux stack or can it be controlled for the control
> >> packets only ? What is the KNI use-case (besides ethtool) and what are
> >>the
> >> best options/choices/strategy to use poll mode driver for data path and
> >> linux for control plane operations ?
> >>
> >> Thanks,
> >> Harish
> >>
> >>
> >>
> >>
> >>
> >>
> >> ________________________________
> >>
> >> This message and any attached documents contain information from QLogic
> >>Corporation or its wholly-owned subsidiaries that may be
> >> confidential. If you are not the intended recipient, you may not read,
> >>copy, distribute, or use this information. If you have received this
> >> transmission in error, please notify the sender immediately by reply
> >>e-mail and then delete this message.
> >
> 
> 
> 
> ________________________________
> 
> This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be
> confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this
> transmission in error, please notify the sender immediately by reply e-mail and then delete this message.