7

When running "ethtool eth0",

  • I get a line in the output that states -> Supported pause frame use: No

    1. Does this mean my Ethernet card does not support flow control at all?

I try to enable the flow control with "ethtool -A eth0 rx on tx on",

  • Nothing happens, the command executes but then "ethtool -a eth0" still reports that it is off

    1. Auto negotiation appears on, but I am unsure if this effects flow control. From what I see, it can determine link flow control?

    2. I question ethtool because when looking online at the specs of my Ethernet card, it looks like it fully supports flow control?

    3. Lastly, I am hooked to a layer 2 switch. Does auto-negotiate have to be on for both endpoints to determine flow control?

All in all, I just want to enable flow control on a host and a switch

EDIT

Intel® Ethernet Controller X540-AT2

2
  • You need to provide more detail. What are the device models and software versions?
    – Ron Maupin
    Jan 14, 2016 at 16:33
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 5, 2021 at 2:47

2 Answers 2

5

Most of this doesn't matter, ethernet flow control has never been widely supported and most switch devices will respect PAUSE frames, but not send them. That being said, your questions can be addressed fairly easily:

  1. Not exactly. You can still send pause frames, but your card won't respect ones sent by the switch (which you will likely never get anyhow). The driver probably doesn't send pause frames though, so any you send would have to be generated manually.

  2. Autonegotiation has no effect on flow control on full-duplex gigabit links

  3. Ethtool is responding with information from the NIC driver. It doesn't matter what the hardware supports if the driver doesn't support it, so what ethtool is telling you is important.

  4. No. Unless you're working at 100Mbit, autonegotiation in general isn't going to help you (unless you're working with repeaters or other rare half-duplex gear at gigabit).

9
  • 1
    Actually, the 1 Gb ethernet standard does have half duplex. There was a big push to remove it from the standard, but it was included. Half duplex was successfully excluded from the 10 Gb ethernet standard.
    – Ron Maupin
    Jan 14, 2016 at 16:55
  • 1
    @RonMaupin: that's true, although the spec provision for this is generally only used for copper repeaters (which at this point are pretty rare). As a practical matter it isn't supported, although I'll update my answer. Jan 14, 2016 at 17:06
  • 1. So I can only send pause frames manually, but otherwise ethtool saying it doesn't support it, is true? 2. link, pg 94 states autonegotiation determines link flow control....is that statement false?
    – user_ABCD
    Jan 14, 2016 at 17:33
  • 1
    @larkym: 1) PAUSE frames are not particularly special, and you can source them from userspace on any NIC (it won't stop you). "Non-support" in ethtool means the driver won't send them, and it won't respect when it receives them from your peer. 2) At non-gigabit speeds, various factors go into flow control on that device (X540). I will revise my answer to make the fact that it applies to gigabit only to be more clear. Jan 14, 2016 at 18:41
  • 1
    @user_ABCD: I don't know how to make this more clear - "non-support" means that your ethernet card will not treat PAUSE frames in any special way. It will not back off transmitting as requested by the control message in the frame. It will receive the frame, and you can send one, but they will be handled (by your NIC) like any other packet. Jan 14, 2016 at 19:20
7

You were closer than you think to getting it working. In fact the problem may have simply been that flow control wasn't enabled on the switch.

The ethtool source code (rev 3.18) and a register interface for a part I'm familiar with, reveal an explanation for the behavior you observed. The 802.3x standard defines flow-control, but I haven't looked there in a while.

Flow Control (MAC Pause) is enabled during Auto-Negotiation with 2 bits in one of the exchanged pages. It has effect only if duplex is enabled. It's also handled at the MAC layer and can be handled in hardware. So, it's possible your driver doesn't get involved at all except for setting the register bits used for Auto-Negotiation. I haven't seen a driver that actively handles MAC layer Pause frames, but then I've only worked with a few.

You started with:

ethtool -A eth0 tx on rx on

Then, you need to make sure auto-negotiation is enabled and restart it.

ethtool -A eth0 autoneg on

ethtool -r eth0

2
  • 1
    I ended up getting something that seemed like it was enabled. I turned it on for my port in the switch and it automatically turned the pause parameters on (for the host NIC) because auto-negotiation was already on. I then queried the driver for statistics. I ended up getting rx_flowcontrol_xon: <10 & rx_flowcontrol_xoff: >100,000. According to link, this may mean that I have slow PCI express and/or memory.
    – user_ABCD
    Jan 16, 2016 at 16:43
  • 1
    There is not enough information here to know what the source of the high rx_flowcontrol counts is. The article the link points to doesn't give enough technical detail, so it may or may not have to do with the PCI express bus implementation. From this point on, it's just analysis. Consider why you're looking at flow control at all. Consider the application, its implementation, expected performance or behavior, hardware at source and destination. A discussion like that is out of scope for this forum so you'll just have to dig deeper on your own.
    – MikeLRoy
    Jan 19, 2016 at 3:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.