DPDK patches and discussions
 help / color / mirror / Atom feed
* why DPDK reassembles IP fragment packets with AF_PACKET
@ 2024-01-08 11:07 钟
  2024-01-08 16:42 ` Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: 钟 @ 2024-01-08 11:07 UTC (permalink / raw)
  To: dev

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

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.


Can you help explain design at your convenience?


I would appreciate your kindly help.


Best regards,


Matthew

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: why DPDK reassembles IP fragment packets with AF_PACKET
  2024-01-08 11:07 why DPDK reassembles IP fragment packets with AF_PACKET@ 2024-01-08 16:42 ` Stephen Hemminger
  2024-01-09  1:00   ` 
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2024-01-08 16:42 UTC (permalink / raw)
  To: 钟; +Cc: dev

On Mon, 8 Jan 2024 19:07:20 +0800 (CST)
钟 <gdsgsx2002@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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: why DPDK reassembles IP fragment packets with AF_PACKET
  2024-01-08 16:42 ` Stephen Hemminger
@ 2024-01-09  1:00   ` 钟
  0 siblings, 0 replies; 3+ messages in thread
From: 钟 @ 2024-01-09  1:00 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

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@networkplumber.org> wrote:
>On Mon, 8 Jan 2024 19:07:20 +0800 (CST)
>钟 <gdsgsx2002@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.

[-- Attachment #2: Type: text/html, Size: 2652 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-01-09  7:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-08 11:07 why DPDK reassembles IP fragment packets with AF_PACKET 钟
2024-01-08 16:42 ` Stephen Hemminger
2024-01-09  1:00   ` 

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).