[dpdk-dev] [PATCH] port: fix doxygen
> fix doxygen for rte_port_out_op_flush. > > Signed-off-by: Yao Zhao Acked-by: Thomas Monjalon Applied for version 1.7.1 Thanks -- Thomas
[dpdk-dev] [PATCH] nic_uio: add device ids for i40e devices
> > The FreeBSD nic_uio driver was missing the #defines to include the device > > ids > > for devices using the i40e driver. This change adds in the missing defines. > > > > Signed-off-by: Bruce Richardson > > Acked-by: Helin Zhang Applied for version 1.7.1 Thanks -- Thomas
[dpdk-dev] [PATCH] makefile: Substituted deprecated default target in app Makefile
> L3fwd-acl and ip pipeline apps were using old > x86_64-default-linuxapp-gcc as their default target, > instead of x86_64-native-linuxapp-gcc > > Signed-off-by: Pablo de Lara Acked-by: Thomas Monjalon Applied for version 1.7.1 Thanks -- Thomas
[dpdk-dev] [PATCH 0/6] Clang compilation support on FreeBSD and Linux
2014-07-08 00:36, Bruce Richardson: > This patch set enables clang compilation on FreeBSD and Linux. It includes > patches to fix a number of compilation errors thrown up by clang, and then > adds in the appropriate toolchain makefiles and compile-time configurations. > > This set has been tested with clang v3.3 on FreeBSD 10 and clang v3.4 on > Fedora linux 20. The example apps folder has not been tested at this time, > this > patch set only focuses on the core libraries and apps. > > Bruce Richardson (6): > pmd_bond: add missing variable initialization > Makefiles: add clang to compiler if/else block > mk: Ensure correct detection of SSE4.2 on FreeBSD > acl: add nmmintrin.h header to allow clang compilation > mk: add toolchain for clang and linuxapp target > config: add compile target for clang on BSD Tested-by: Zhaochen Zhan Acked-by: Thomas Monjalon Applied with some cleanups for version 1.7.1 Thanks -- Thomas
[dpdk-dev] [PATCH v2] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex
2014-07-17 15:24, Alex Markuze: > On Thu, Jul 17, 2014 at 3:02 PM, Thomas Monjalon > > 2014-07-11 23:37, Yao-Po Wang: > >> Per netif_receive_skb function description, it may only be called from > >> interrupt contex, but KNI is run on kthread that like as user-space > >> contex. It may occur deallock, if netif_receive_skb called from kthread, > >> so it should be repleaced by netif_rx or adding local_bh_disable/enable > >> around netif_receive_skb. > >> > >> Signed-off-by: Yao-Po Wang > > > >> --- a/lib/librte_eal/linuxapp/kni/kni_net.c > >> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c > >> /* Call netif interface */ > >> - netif_receive_skb(skb); > >> + netif_rx(skb); > > > > Is there someone confident to approve this change? > > Yao-Po is correct. > > Please see this comment In Linux source code . > http://lxr.free-electrons.com/source/net/core/dev.c#L3715 > > Context: > All todays network drivers use(ixgbe is no exception) NAPI which is a > soft irq context of the receive flow . > This is the context in which netif_receive_skb should be called in. > KNI is not soft IRQ context so the generic netif_rx is the > right function. Thanks for confirmation. Assuming Acked-by: Alex Markuze Applied for version 1.7.1 Thanks -- Thomas
[dpdk-dev] [PATCH] kni: allow setting KNI device MAC address
> > Added relevant callback function to change a KNI device's MAC address > > > > Signed-off-by: Padam Jeet Singh > > Reviewed-by: Helin Zhang Applied for version 1.7.1 Thanks -- Thomas
[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.
[dpdk-dev] [PATCH 00/10] igb_uio related patches
2014-07-18 09:14, Stephen Hemminger: > Update patches so all are now bisectable, and incorporate comments. > Also fix the checkpatch warnings that are fixable. I've isolated all MSI additions in the dedicated commit. Acked-by: Thomas Monjalon Applied for version 1.7.1 What are the news about your uio work for kernel.org? Thanks -- Thomas
[dpdk-dev] KNI interface
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 at dpdk.org] On Behalf Of Harish Patil > Sent: Saturday, July 19, 2014 8:09 AM > To: dev at 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.
[dpdk-dev] KNI interface
>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 at dpdk.org] On Behalf Of Harish Patil >> Sent: Saturday, July 19, 2014 8:09 AM >> To: dev at 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.
