> >> >> > >> >> >Hi, >> >> > >> >> >Some comments below. >> >> > >> >> >> >> Hi Flavio, >> >> >> >> Thanks for your review! >> >> >> >> I've responded to your comments inline - I've also addressed the >> >> cosmetic changes that you suggested in V3 of the patch. >> >> >> >> Thanks again, >> >> Mark >> >> >> >> > >> >> >On Mon, 1 Feb 2016 10:18:54 +0000 >> >> >Mark Kavanagh <mark.b.kavan...@intel.com> wrote: >> >> > >> >> >> Add support for Jumbo Frames to DPDK-enabled port types, >> >> >> using single-segment-mbufs. >> >> >> >> >> >> Using this approach, the amount of memory allocated for each mbuf >> >> >> to store frame data is increased to a value greater than 1518B >> >> >> (typical Ethernet maximum frame length). The increased space >> >> >> available in the mbuf means that an entire Jumbo Frame can be >> >> >> carried in a single mbuf, as opposed to partitioning it across >> >> >> multiple mbuf segments. >> >> >> >> >> >> The amount of space allocated to each mbuf to hold frame data is >> >> >> defined dynamically by the user when adding a DPDK port to a >> >> >> bridge. If an MTU value is not supplied, or the user-supplied >> >> >> value is invalid, the MTU for the port defaults to standard >> >> >> Ethernet MTU (i.e. 1500B). >> >> >> >> >> >> Signed-off-by: Mark Kavanagh <mark.b.kavan...@intel.com> >> >> >> --- >> >> >> INSTALL.DPDK.md | 59 +++++++++- >> >> >> NEWS | 2 + >> >> >> lib/netdev-dpdk.c | 347 >> >> >> +++++++++++++++++++++++++++++++++++++++++------------- 3 files >> >> >> changed, 328 insertions(+), 80 deletions(-) >> >[...] >> > >> >> >> +When Jumbo Frames are enabled, the size of a DPDK port's mbuf >> >> >> segments are +increased, such that a full Jumbo Frame may be >> >> >> accommodated inside a single +mbuf segment. Once set, the MTU for a >> >> >> DPDK port is immutable. + >> >> > >> >> >I think we need some protection here because if someone tries to >> >> >change that, it will segfault PMD threads. >> >> > >> >> >> >> Could you elaborate on this a bit more; do you mean that PMD threads >> >> would segfault if a user attempts to change the MTU of a running DPDK >> >> port? If so, how would that be possible (AFAIA, there's no way to >> >> programmatically modify the MTU of OVS ports, outside of standard >> >> Linux utilities such as ifconfig, which DPDK ports typically aren't >> >> subject to; there's also AFAIA no way to programmatically modify MTU >> >> of DPDK ports outside of modifying the source code). >> > >> >I have a ovs bridge with two dpdk ports created with these commands: >> > >> ># ovs-vsctl add-port ovsbr0 dpdk0 \ >> > -- set interface dpdk0 type=dpdk options:dpdk-mtu=9000 >> > ofport_request=10 >> ># ovs-vsctl add-port ovsbr0 dpdk1 \ >> > -- set interface dpdk1 type=dpdk options:dpdk-mtu=9000 >> > ofport_request=11 >> > >> >Now I am pushing traffic (jumbo frames or small frames) and then >> >I change dpdk-mtu to 1500. >> > >> ># ovs-vsctl set interface dpdk1 options:dpdk-mtu=1500 >> > >> >Then I see this: >> >2016-02-12T13:19:20.142Z|00003|daemon_unix(monitor)|ERR|1 crashes: >> >pid 78009 died, killed (Segmentation fault), core dumped, restarting >> >... >> > >> >This is the backtrace: >> >#0 0x00007f1909cf4423 in _recv_raw_pkts_vec () from /lib64/libdpdk.so >> >#1 0x00000000004fd595 in rte_eth_rx_burst (nb_pkts=32, >> >rx_pkts=0x7f18c37fd970, >queue_id=2, >> > port_id=1 '\001') at >> > /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2510 >> >#2 netdev_dpdk_rxq_recv (rxq_=<optimized out>, packets=0x7f18c37fd970, >> >c=0x7f18c37fd96c) >> > at ../lib/netdev-dpdk.c:1216 >> >#3 0x000000000047c3c1 in netdev_rxq_recv (rx=<optimized out>, >> >buffers=buffers@entry=0x7f18c37fd970, >> > cnt=cnt@entry=0x7f18c37fd96c) at ../lib/netdev.c:654 >> >#4 0x000000000045e566 in dp_netdev_process_rxq_port >> >(pmd=pmd@entry=0x1e1cd90, >rxq=<optimized >> >out>, >> > port=<optimized out>, port=<optimized out>) at ../lib/dpif-netdev.c:2555 >> >#5 0x000000000045e9f9 in pmd_thread_main (f_=0x1e1cd90) at >> >../lib/dpif-netdev.c:2691 >> >#6 0x00000000004bab64 in ovsthread_wrapper (aux_=<optimized out>) at >> >../lib/ovs- >thread.c:340 >> >#7 0x00007f1909583555 in start_thread (arg=0x7f18c37fe700) at >> >pthread_create.c:333 >> >#8 0x00007f1908daeb9d in clone () at >> >../sysdeps/unix/sysv/linux/x86_64/clone.S:109 >> > >> > >> >Dump of assembler code for function _recv_raw_pkts_vec: >> > 0x00007fa8d51ccf30 <+0>: push %r15 >> > 0x00007fa8d51ccf32 <+2>: mov %edx,%r15d >> > 0x00007fa8d51ccf35 <+5>: push %r14 >> > 0x00007fa8d51ccf37 <+7>: push %r13 >> > 0x00007fa8d51ccf39 <+9>: push %r12 >> > 0x00007fa8d51ccf3b <+11>: push %rbp >> > 0x00007fa8d51ccf3c <+12>: push %rbx >> > 0x00007fa8d51ccf3d <+13>: sub $0x38,%rsp >> >=> 0x00007fa8d51ccf41 <+17>: movzbl 0x69(%rdi),%eax >> > >> >rdi 0x0 0 >> > >> >Looks like dev->data->rx_queues[queue_id] is NULL. >> > >> >-- >> >fbl >> >> Hi Flavio, >> >> I saw this myself yesterday, when testing out that same scenario which was >> pointed out to >me by Daniele. >> >> I'm currently investigating how to fix the issue, and will hopefully have a >> solution in the >next patchset. > >OK, no worries. You asked to me to elaborate on the segfault issue and >it took some time to get my testbed ready to test it again.
Thanks Flavio - I appreciate the effort! > >-- >fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
