[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PH0PR11MB519201AEC268247F6890157FECB79@PH0PR11MB5192.namprd11.prod.outlook.com>
Date: Tue, 7 Mar 2023 12:56:17 +0000
From: "Song, Xiongwei" <Xiongwei.Song@...driver.com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: "claudiu.manoil@....com" <claudiu.manoil@....com>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"richardcochran@...il.com" <richardcochran@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Response error to fragmented ICMP echo request
Hello Vladimir,
Thanks for the quick response.
> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@....com>
> Sent: Tuesday, March 7, 2023 8:35 PM
> To: Song, Xiongwei <Xiongwei.Song@...driver.com>
> Cc: claudiu.manoil@....com; alexandre.belloni@...tlin.com;
> UNGLinuxDriver@...rochip.com; davem@...emloft.net; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; richardcochran@...il.com; linux-
> kernel@...r.kernel.org; netdev@...r.kernel.org
> 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
Powered by blists - more mailing lists