Eric W. Biederman wrote: > "Denis V. Lunev" <den@xxxxx> writes: > >> Kirill Korotaev wrote: >>> if network device inside container has MTU higher then eth0 outside the >> container, >>> then packets will get fragmented. >>> First time to MTU1 inside container and refragmented to MTU2 >>> outside the container. At least this is the reason we use ethernet MTU >>> on venet devices in OpenVZ - to avoid framentation. >> frankly speaking, there are another points, which can call to >> pskb_expand_head. Hard header size on container network device should be >> the same as on real one. > > I believe it is the case that I have a 1500 byte mtu with an ethernet header. > Although it may be I didn't reserve extra hard header space or something like > that. My investigations on the increase of cpu load when running netperf inside a container (ie. through etun2<->etun1) is progressing slowly. I'm not sure the cause is fragmentation as we supposed initially. In fact, it seems related to forwarding the packets between the devices. Here is what I've tracked so far: * when we run netperf from the container, oprofile reports that the top "consuming" symbol is: "pskb_expand_head". Next comes "csum_partial_copy_generic". these symbols represents respectively 13.5% and 9.7% of the samples. * Without container, these symbols don't show up in the first 20 entries. Who is calling "pskb_expand_head" in this case? Using systemtap, I determined that the call to "pskb_expand_head" comes from the skb_cow() in ip_forward() (l.90 in 2.6.20-rc5-netns). The number of calls to "pskb_expand_head" matches the number of invocations of ip_forward() (268000 calls for a 20 seconds netperf session in my case). Here is an example of the backtrace when we reach pskb_expand_head: 0xc028bb95 : pskb_expand_head+0x1/0x11b [] 0xc02ab5fe : ip_forward+0x150/0x256 [] 0xc02a9e9b : ip_rcv_finish+0xae/0xcb [] 0xc02aa314 : ip_rcv+0x207/0x231 [] 0xc031a0eb : notifier_call_chain+0x19/0x29 [] 0xc02902eb : netif_receive_skb+0x1e3/0x24e [] 0xc0291c60 : process_backlog+0x76/0xe3 [] 0xc0292048 : net_rx_action+0x94/0x14e [] 0xc0126e4d : __do_softirq+0x5d/0xba [] 0xc0126edc : do_softirq+0x32/0x36 [] 0xc01270a8 : local_bh_enable+0x7b/0x89 [] 0xc0292329 : dev_queue_xmit+0x227/0x246 [] 0xc031a0eb : notifier_call_chain+0x19/0x29 [] 0xc02aef41 : ip_output+0x1e6/0x221 [] 0xc02902eb : netif_receive_skb+0x1e3/0x24e [] 0xc02ae741 : ip_queue_xmit+0x3a8/0x3ea [] 0xc02c10cc : tcp_v4_send_check+0x74/0xaa [] 0xc02bc22a : tcp_transmit_skb+0x606/0x634 [] 0xc02aef41 : ip_output+0x1e6/0x221 [] 0xc02bdcec : tcp_push_one+0xb3/0xd8 [] 0xc02b429a : tcp_sendmsg+0x7c8/0x9f9 [] 0xc01cbe8a : vsnprintf+0x450/0x48c [] 0xc02cc10f : inet_sendmsg+0x3b/0x45 [] 0xc0286e17 : sock_sendmsg+0xd0/0xeb [] 0xc017be75 : seq_printf+0x2e/0x4b [] 0xc0133591 : autoremove_wake_function+0x0/0x35 [] 0xc0287691 : sys_sendto+0x116/0x140 [] 0xc02876f2 : sys_send+0x37/0x3b [] 0xc0288057 : sys_socketcall+0x14a/0x261 [] 0xc0102d6c : syscall_call+0x7/0xb [] Also here is a backtrace when etun_xmit() is called: tx_dev: etun1 rx_dev: etun2 0xf8b4a3b4 : etun_xmit+0x1/0xed [etun] 0xc02906e0 : dev_hard_start_xmit+0x1ab/0x204 [] 0xc029229d : dev_queue_xmit+0x19b/0x246 [] 0xc0296672 : neigh_resolve_output+0x1f5/0x227 [] 0xc02aef41 : ip_output+0x1e6/0x221 [] 0xc02ab4ac : ip_forward_finish+0x2c/0x2e [] 0xc02ab6a5 : ip_forward+0x1f7/0x256 [] <- ip_forward 0xc0292329 : dev_queue_xmit+0x227/0x246 [] 0xc02a9e9b : ip_rcv_finish+0xae/0xcb [] 0xc02aa314 : ip_rcv+0x207/0x231 [] 0xc028c0cd : __alloc_skb+0x4f/0xf8 [] 0xc02902eb : netif_receive_skb+0x1e3/0x24e [] 0xc0291c60 : process_backlog+0x76/0xe3 [] 0xc0292048 : net_rx_action+0x94/0x14e [] 0xc0126e4d : __do_softirq+0x5d/0xba [] 0xc0126edc : do_softirq+0x32/0x36 [] 0xc0104d2f : do_IRQ+0x87/0x9c [] 0xc0103707 : common_interrupt+0x23/0x28 [] 0xc0101c30 : default_idle+0x0/0x3e [] 0xc031007b : packet_set_ring+0x2d7/0x2ea [] 0xc0101c5c : default_idle+0x2c/0x3e [] 0xc0101390 : cpu_idle+0x9e/0xb7 [] That's it for now. I hope this helps. Regards, Benjamin > > Eric > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/containers > -- B e n j a m i n T h e r y - BULL/DT/Open Software R&D http://www.bull.com _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers