why DPDK reassembles IP fragment packets with AF_PACKET

gdsgsx2002 at 163.com
Tue Jan 9 02:00:02 CET 2024


Hi Stephen,


Thank you for immediate response.


When PACKET_FANOUT_FLAG_DEFRAG flag is removed in AF_PACKET mode, IP fragment packets cannot be reassembled. That is what we expected or OVS expected.


The file drivers/net/af_packet/rte_net_af_packet.c +770
#if defined(PACKET_FANOUT) fanout_arg = (getpid() ^ (*internals)->if_index) & 0xffff; fanout_arg |= (PACKET_FANOUT_HASH | PACKET_FANOUT_FLAG_DEFRAG) << 16; ==> fanout_arg |= (PACKET_FANOUT_HASH) << 16; #if defined(PACKET_FANOUT_FLAG_ROLLOVER) fanout_arg |= PACKET_FANOUT_FLAG_ROLLOVER << 16; #endif #endif


Best regards,


Matthew














At 2024-01-09 00:42:32, "Stephen Hemminger" <stephen at networkplumber.org> wrote:
>On Mon, 8 Jan 2024 19:07:20 +0800 (CST)
>钟 <gdsgsx2002 at 163.com> wrote:
>
>> Hi All,
>> 
>> 
>> Recently I debug ovs-dpdk with AF_PACKET mode.  When IP fragment packets are received via DPDK, the IP fragment packets are reassembled by DPDK. After reassembly, the packet length is over 1518. They are discarded by OVS because of oversize packets.
>> 
>> 
>> I don't understandy why  PACKET_FLAG_DEFRAG is set for AF_PACKET mode.
>> 
>> 
>
>Not sure, but it looks like the af_packet wants to hash packets for fanout.
>Hashin of fragments won't work correctly, and packet will arrive on different queues if fragmented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20240109/08da964e/attachment.htm>


More information about the dev mailing list