RE: Response error to fragmented ICMP echo request

[Song, Xiongwei]

Hello Vladimir,

Thanks for the quick response.

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@xxxxxxx>
> Sent: Tuesday, March 7, 2023 8:35 PM
> To: Song, Xiongwei <Xiongwei.Song@xxxxxxxxxxxxx>
> Cc: claudiu.manoil@xxxxxxx; alexandre.belloni@xxxxxxxxxxx;
> UNGLinuxDriver@xxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx;
> kuba@xxxxxxxxxx; pabeni@xxxxxxxxxx; richardcochran@xxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx
> Subject: Re: Response error to fragmented ICMP echo request
> 
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> Hello Xiongwei,
> 
> On Tue, Mar 07, 2023 at 12:11:52PM +0000, Song, Xiongwei wrote:
> > ......snip......
> > failing SW:
> > rx_octets                       +64
> > rx_unicast                      +1
> > rx_frames_below_65_octets       +1
> > rx_yellow_prio_0                +1
> > *drop_yellow_prio_0              +1
> > ......snip......
> >
> > 3). From pcap file(the pcap was collected on the senderside (VM))
> >
> > Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
> > Ethernet II, Src: 7c:72:6e:d4:44:5f (7c:72:6e:d4:44:5f), Dst: aa:3a:b3:e7:67:5c
> (aa:3a:b3:e7:67:5c)
> >     Destination: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c)
> >     Source: 7c:72:6e:d4:44:5f (7c:72:6e:d4:44:5f)
> >     Type: 802.1Q Virtual LAN (0x8100)
> > 802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 981
> >     110. .... .... .... = Priority: Internetwork Control (6)
> >     ...0 .... .... .... = DEI: Ineligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: ARP (0x0806)
> >     Padding: 0000000000000000000000000000
> >     Trailer: 00000000
> >
> > Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...0 .... .... .... = DEI: Ineligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: ARP (0x0806)
> >
> > Frame 3: 47 bytes on wire (376 bits), 47 bytes captured (376 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 1, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...1 .... .... .... = DEI: Eligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: IPv4 (0x0800)
> >
> > Frame 4: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
> > Ethernet II, Src: aa:3a:b3:e7:67:5c (aa:3a:b3:e7:67:5c), Dst: 7c:72:6e:d4:44:5f
> (7c:72:6e:d4:44:5f)
> > 802.1Q Virtual LAN, PRI: 0, DEI: 1, ID: 981
> >     000. .... .... .... = Priority: Best Effort (default) (0)
> >     ...1 .... .... .... = DEI: Eligible
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> >     .... 0011 1101 0101 = ID: 981
> >     Type: IPv4 (0x0800)
> >
> > 4). What we've found so far
> >
> > According binary search, we found out the following commit causes this issue:
> > a4ae997adcbd("net: mscc: ocelot: initialize watermarks to sane defaults").
> > Without this commit the test case was passed.
> >
> > Could you please take a look? Please let me know if you need more debug info.
> 
> I've marked the DEI values in the message you posted above.
> 
> Commit a4ae997adcbd ("net: mscc: ocelot: initialize watermarks to sane defaults")
> tells the hardware to not allow frames with DEI=1 consume from the shared switch
> resources (buffers / frame references) by default. Drop Eligible Indicator = 1
> means "eligible for dropping". The only chance for DEI=1 frames to not be dropped
> is to set up a resource reservation for that stream, via the devlink-sb command.

Oh.., thanks for the detailed explanation.

> 
> Frames 3 and 4 are sent with DEI=1 and are dropped, frames 1 and 2 are
> sent with DEI=0 and are not dropped. I'm not sure if varying the DEI
> field is part of the intentions of the test? Is there any RFC which says
> that IP fragments over VLAN should use DEI=1, or some other reason?

I didn't notice that. Let me check the test why set DEI=1. 

Have a good day.

Regards,
Xiongwei