Julia, I think you are still missing how this works. When a pause frame is received by an interface it will only hold off transmission of packets if are packets in a buffer still waiting to be transmitted, meaning that the link is saturated. Using ping will not saturate the link (no packets queued up to transmit). So I don't think you are going to see a delay in the packets. On a saturated link where packets are queued link on the switch side of a connection where the switch has to hold back on the sending due to receiving an XOFF packet you would see the packets pause for the configured time. There are tools out on the web to configure and send pause frames. I suggest to use one of these tools to configure the pause to be the maximum that can be set and send it to a switch port that has a backlog (buffered packets) to see it pause.
Again, are you just trying to see that pause frame works with our HW and drivers? Like for some sort of validation that they actually work? Cheers, John > -----Original Message----- > From: Julia Niewiejska [mailto:julia.niewiej...@fkie.fraunhofer.de] > Sent: Thursday, November 6, 2014 5:31 AM > To: Ronciak, John > Cc: e1000-devel@lists.sourceforge.net > Subject: Re: [E1000-devel] 802.3x pause frames > > Hi, > > On 11/06/2014 06:15 AM, Ronciak, John wrote: > > Julia, > > > > First we can't help you with your Realtec issue. Not our driver. > > > > The only time when you'll notice actual pauses in traffic due to XON/XOFF > will be when the link is saturated to the point where packets would be > dropped with the HW (on the end that is XON/XOFF enabled). So in using > ping it would be doubtful that you would ever be in a situation where > packets would be dropped. > > > > Ping was suggested in [1] as a test for whether it's working. I also tried > saturating the link with UDP packets in the setup with 2 physical machines > where the link speed was set to 10 Mbps. I used iperf for this purpose, > started the transmission from first to second machine, and simulaneously > used the tool from [1] to generate a couple of pause frames at arbitrary > times on the second machine. I captured the traffic at the second machine > and considered the timestamps. > > According to the standard, the network adapter pauses the transmission > completely on the reception of a pause frame for the time specified. > Therefore I would expect to see noticeable variations in the intervals > between consecutive packets at the time when I generated the pause > frames. However there were no significant variations to be seen. > > > Regards, > > Julia Niewiejska > > > [1] > http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow- > ctrl > > > Im not sure where you ae going with this. Do you not believe that packets > are being paused to the correct amount of time due the XON/XOFF settings? > Also, you should be trying to use a connection to a switch port that is > enabled > for XON/XOFF. I think no matter how you are going to test this you will need > to use something like pktgen or other type of packet generator to generate > enough traffic to saturate the link enough for XON/XOFF to engage. > > > > Cheers, > > John > > > >> -----Original Message----- > >> From: Julia Niewiejska [mailto:julia.niewiej...@fkie.fraunhofer.de] > >> Sent: Wednesday, November 5, 2014 12:19 AM > >> To: e1000-devel@lists.sourceforge.net > >> Subject: [E1000-devel] 802.3x pause frames > >> > >> Hello, > >> > >> I indend to do some experiments with 802.3x pause frames, but I have > >> yet to find a setup that works. I used a tool that generates pause > >> frames [1] in two setups. First one consists of two virtual machines > >> on a VMWare ESXi 5.5 server connected with each other through a > >> virtual switch. In second setup two physical machines (Desktop PCs) > >> were connected directly by an ethernet cable. The VMs are running > >> Debian Wheezy 32bit while Debian Testing > >> (Jessie) 64bit is installed on both desktop PCs. Below you will find > >> some information on the ethernet adapters and drivers used in the VM > >> [2], the desktop PC with the more up to date hardware [3] and the > >> older machine [4]. I used the following command to activate flow control: > >> > >> ethtool -A <eth> autoneg off rx on tx on > >> > >> First of all I noticed some discrepancies between the output of > >> mii-tools or ethtool -a and the attempt to change the flow control > >> settings with the command above. Only the Realtek adapter actually > >> output that it didn't support the operation, the other adapters > >> accepted the settings without any error message. > >> > >> In both setups pause frames were generated on one machine while a > >> ping was sent simultaneously, as suggested in [1]. While the VM > >> connection was set to 1 Gbps the whole time, I also tested a 10 Mbps > >> setting on the physical connection. Even though the pause frames were > >> always visible in tcpdump at the receiver, I didn't notice any influence > whatsoever in the ping results. > >> > >> Did I miss some important settings that activate pause frame support, > >> or is it possible that none of those different ethernet adapters and > >> modules that were tested support at least the reception of pause > frames? > >> If so, are there any adapters that do support them? I'm also not sure > >> how to interpret the output of ethtool. E.g. what does "Advertised > >> pause frame use" mean, exactly? > >> > >> > >> Many thanks. > >> > >> Julia Niewiejska > >> > >> > >> [1] > >> > http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow- > >> ctrl > >> > >> > >> ---------------------------------------------- > >> [2] Virtual machine on VMWare ESXi 5.5: Debian Wheezy 32bit, kernel > >> 3.2 > >> > >> *** lspci -v *** > >> > >> 02:02.0 Ethernet controller: Intel Corporation 82545EM Gigabit > >> Ethernet Controller (Copper) (rev 01) > >> Subsystem: VMware PRO/1000 MT Single Port Adapter > >> Physical Slot: 34 > >> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 16 > >> Memory at fd5a0000 (64-bit, non-prefetchable) [size=128K] > >> Memory at fdfe0000 (64-bit, non-prefetchable) [size=64K] > >> I/O ports at 2040 [size=64] > >> [virtual] Expansion ROM at ebb10000 [disabled] [size=64K] > >> Capabilities: [dc] Power Management version 2 > >> Capabilities: [e4] PCI-X non-bridge device > >> Kernel driver in use: e1000 > >> > >> > >> *** mii-tool -v *** > >> > >> eth1: negotiated 1000baseT-FD flow-control, link ok > >> product info: Yukon 88E1011 rev 3 > >> basic mode: autonegotiation enabled > >> basic status: autonegotiation complete, link ok > >> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD > >> advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD > >> 10baseT-FD 10baseT-HD > >> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD > >> > >> > >> > >> *** ethtool eth1 *** > >> > >> Settings for eth1: > >> Supported ports: [ TP ] > >> Supported link modes: 10baseT/Half 10baseT/Full > >> 100baseT/Half 100baseT/Full > >> 1000baseT/Full > >> Supported pause frame use: No > >> Supports auto-negotiation: Yes > >> Advertised link modes: 10baseT/Half 10baseT/Full > >> 100baseT/Half 100baseT/Full > >> 1000baseT/Full > >> Advertised pause frame use: No > >> Advertised auto-negotiation: Yes > >> Speed: 1000Mb/s > >> Duplex: Full > >> Port: Twisted Pair > >> PHYAD: 0 > >> Transceiver: internal > >> Auto-negotiation: on > >> MDI-X: Unknown > >> Supports Wake-on: d > >> Wake-on: d > >> Current message level: 0x00000007 (7) > >> drv probe link > >> Link detected: yes > >> > >> *** ethtool -a eth1 *** > >> > >> Pause parameters for eth1: > >> Autonegotiate: on > >> RX: off > >> TX: off > >> > >> ---------------------------------------------- > >> [3] Desktop PC 1: Debian Jessie 64bit, kernel 3.16 > >> > >> *** lspci -v *** > >> > >> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > >> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) > >> Subsystem: ASUSTeK Computer Inc. Device 8554 > >> Flags: bus master, fast devsel, latency 0, IRQ 44 > >> I/O ports at d000 [size=256] > >> Memory at f7100000 (64-bit, non-prefetchable) [size=4K] > >> Memory at f2100000 (64-bit, prefetchable) [size=16K] > >> Capabilities: [40] Power Management version 3 > >> Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > >> Capabilities: [70] Express Endpoint, MSI 01 > >> Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > >> Capabilities: [d0] Vital Product Data > >> Capabilities: [100] Advanced Error Reporting > >> Capabilities: [140] Virtual Channel > >> Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00 > >> Capabilities: [170] Latency Tolerance Reporting > >> Kernel driver in use: r8169 > >> > >> *** mii-tool -v *** > >> > >> eth0: negotiated 1000baseT-FD flow-control, link ok > >> product info: vendor 00:07:32, model 0 rev 0 > >> basic mode: autonegotiation enabled > >> basic status: autonegotiation complete, link ok > >> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD > >> advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD > >> 10baseT-FD 10baseT-HD flow-control > >> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD flow-control > >> > >> *** ethtool eth0 *** > >> > >> Settings for eth0: > >> Supported ports: [ TP MII ] > >> Supported link modes: 10baseT/Half 10baseT/Full > >> 100baseT/Half 100baseT/Full > >> 1000baseT/Half 1000baseT/Full > >> > >> Supported pause frame use: No > >> > >> Supports auto-negotiation: Yes > >> > >> Advertised link modes: 10baseT/Half 10baseT/Full > >> > >> 100baseT/Half 100baseT/Full > >> > >> 1000baseT/Full > >> > >> Advertised pause frame use: Symmetric Receive-only > >> > >> Advertised auto-negotiation: Yes > >> > >> Link partner advertised link modes: 10baseT/Half > >> 10baseT/Full > >> > >> 100baseT/Half > >> 100baseT/Full > >> 1000baseT/Half > >> 1000baseT/Full > >> Link partner advertised pause frame use: Symmetric > >> Receive-only > >> > >> Link partner advertised auto-negotiation: Yes > >> > >> Speed: 1000Mb/s > >> > >> Duplex: Full > >> > >> Port: MII > >> > >> PHYAD: 0 > >> > >> Transceiver: internal > >> > >> Auto-negotiation: on > >> > >> Supports Wake-on: pumbg > >> > >> Wake-on: g > >> > >> Current message level: 0x00000033 (51) > >> > >> drv probe ifdown ifup > >> > >> Link detected: yes > >> > >> *** ethtool -a eth0 *** > >> > >> Pause parameters for eth0: > >> Cannot get device pause settings: Operation not supported > >> > >> > >> ---------------------------------------------- > >> [4] Desktop PC 2: Debian Jessie 64bit, kernel 3.16 > >> > >> *** lspci -v *** > >> > >> 00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit > >> Network Connection (rev 05) > >> Subsystem: Hewlett-Packard Company Device 304b > >> > >> Flags: bus master, fast devsel, latency 0, IRQ 43 > >> > >> Memory at f0400000 (32-bit, non-prefetchable) [size=128K] > >> Memory at f0425000 (32-bit, non-prefetchable) [size=4K] > >> I/O ports at 2100 [size=32] > >> Capabilities: [c8] Power Management version 2 > >> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > >> Capabilities: [e0] PCI Advanced Features > >> Kernel driver in use: e1000e > >> > >> *** mii-tool -v *** > >> > >> eth1: negotiated 1000baseT-FD flow-control, link ok > >> product info: vendor 00:13:74, model 4 rev 0 > >> basic mode: autonegotiation enabled > >> basic status: autonegotiation complete, link ok > >> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD > >> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD flow-control > >> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD > >> 10baseT-HD flow-control > >> > >> *** ethtool eth1 *** > >> > >> Settings for eth1: > >> Supported ports: [ TP ] > >> Supported link modes: 10baseT/Half 10baseT/Full > >> 100baseT/Half 100baseT/Full > >> 1000baseT/Full > >> Supported pause frame use: No > >> Supports auto-negotiation: Yes > >> Advertised link modes: 10baseT/Half 10baseT/Full > >> 100baseT/Half 100baseT/Full > >> 1000baseT/Full > >> Advertised pause frame use: No > >> Advertised auto-negotiation: Yes > >> Speed: 1000Mb/s > >> Duplex: Full > >> Port: Twisted Pair > >> PHYAD: 2 > >> Transceiver: internal > >> Auto-negotiation: on > >> MDI-X: off (auto) > >> Supports Wake-on: pumbg > >> Wake-on: g > >> Current message level: 0x00000007 (7) > >> drv probe link > >> Link detected: yes > >> > >> *** ethtool -a eth1 *** > >> > >> Pause parameters for eth1: > >> Autonegotiate: on > >> RX: on > >> TX: off > >> > >> --------------------------------------------------------------------- > >> --------- _______________________________________________ > >> E1000-devel mailing list > >> E1000-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/e1000-devel > >> To learn more about Intel® Ethernet, visit > >> http://communities.intel.com/community/wired > > -- > Dipl.-Inform. Julia Niewiejska > Kommunikationssysteme (KOM) > > Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und > Ergonomie FKIE Fraunhoferstraße 20 > D-53343 Wachtberg > Tel.: +49 (0)228 9435-609 > Mail: julia.niewiej...@fkie.fraunhofer.de > http://www.fkie.fraunhofer.de ------------------------------------------------------------------------------ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
