On 11/10/2014 01:42 AM, Julia Niewiejska wrote:
> Hi,
>
> On 11/07/2014 07:09 AM, Ronciak, John wrote:
>> 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.
> I get it. Therefore I also tried saturating a link with UDP traffic.
>
> 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.
>
> Like I already mentioned, that is exactly what I am trying to do. I'm
> using a tool that can send pause frames with a configured pause time. I
> also validated (by capturing the packets), that those pause frames I
> send with the tool are being received by the sender of the UDP traffic.
> The adapter just seems to completely ignore the pause frames.
Where are you capturing the pause frame? It is possible that your
transmitting adapter is not sending the frame, of the destination MAC
address is not correct, or that it is not being sent with a valid CRC.
Normally the Intel adapters will internally terminate pause frames and I
don't believe the driver is configured to enable pause frame pass
through in promiscuous mode so if you are seeing frames on the Intel
side it would likely mean that something is wrong as that is not the
normal behaviour for the driver.
>> 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?
> That would be the first step. I'm working on flow control for switches.
> But I can't validate that the reception of the artificially created
> pause frames has any influence on the adapter.
>
>
> Regards,
>
> Julia Niewiejska
First I would not recommend going through a vport on a switch. Odds are
the switch will just drop the frame since the MAC address is not
forwardable. I would recommend sending the xoff frames from the realtek
since it likely cannot receive them.
You should be able to generate a flow control frame by running the
following:
echo 0000 01 80 C2 00 00 01 00 00 00 00 00 00 88 08 00 01 FF FF 00 00 |
text2pcap - /tmp/flow-control.pcap
Once you have that you should be able to simply send a pause frame using
tcpreplay and issuing the following command:
tcpreplay -p 300 -l 600 -i eth0 /tmp/flow-control.pcap
With that command it should stop traffic for about 2 seconds, which
should be long enough that it is obvious even with ping if you are
seeing the frames recognized. You can also check ethtool -S eth1 on the
Intel adapter to verify if any flow control events were found in the
statistics.
- Alex
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
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
