Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
So i have a system that is on two different networks. Each NIC is on its own subset etc. I was seeing a huge amount of issues with one of ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Mar 2008
    Posts
    47

    Turning off GRO on startup


    So i have a system that is on two different networks. Each NIC is on its own subset etc.

    I was seeing a huge amount of issues with one of them, and it turned out it had:
    generic-receive-offload: on

    Once i turned this off with "ethtool -K eth1 gro off", everything is working fine. HOWEVER when i reboot, it gets re-enabled.

    Is there a way to turn this off on startup?

    [I do realise i can turn it off by adding to rc.local, i am just wondering if there is a "cleaner" method]

  2. #2
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,307
    Have you tried putting them in the appropriate ifcfg config file? e.g.

    Code:
    # /etc/sysconfig/network-scripts/ifcfg-eth0
    DEVICE="eth0"
    ONBOOT="yes"
    ETHTOOL_OPTS="gro off"
    That is untested, but I think that is where it would go.
    Last edited by atreyu; 11-21-2011 at 08:44 PM. Reason: off!

  3. #3
    Just Joined!
    Join Date
    Mar 2008
    Posts
    47
    Doesnt seem to be working. However I cant reboot this system until 30th December, so im testing on another machine by trying to turn GRO on at boot using "gro on".

  4. #4
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,307
    Does that device on the other machine take the "gro on" command from the command line okay? Probably so, just checking...

  5. #5
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,307
    Okay, seems using ethtool with -K type options in network-scripts is a bug.

    There is a patch listed on the bug report that would allow you to do something like:

    Code:
    ETHTOOL_OPTS_OFFLOAD="gro off"
    But you'd have to keep track of that file and make sure that updates to the package that own the patched file(s) don't get overwritten.

    Or you could make it a udev rule like is suggested in the bug report...

  6. #6
    Just Joined!
    Join Date
    Mar 2008
    Posts
    47
    Yeah - checked that before i rebooted

  7. #7
    Just Joined!
    Join Date
    Mar 2008
    Posts
    47
    Giving it a look now. To be honest, I will probably go with the entry to rc.local. I dont get to patch these machines. Ever. They have to be used with specific RHEL version, specific drivers, kernels etc.

    Thanks for all your help mate!

  8. #8
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,307
    Yeah, I understand that. Just keep in mind that putting it in rc.local might only affect it upon start-up, i.e., do you know if that change is persistent across network restarts?

    e.g., if you do:

    Code:
    service network restart
    Is gro stilll off?

  9. #9
    Just Joined!
    Join Date
    Mar 2008
    Posts
    47
    Like i said, I am working with gro "on" in a VM for testing purposes (same version of RHEL etc).

    Added to rc.local, it started with it on. When i ran "service network restart" it stayed on. I would rather get the patch in place, but this will do until my next downtime at a pinch.

    And realistically, i dont get to run service network restart. Ever. I never get to do anything on the systems outside downtime (they are in use 24/7 and i get maybe 4 downtimes a year)

  10. #10
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,307
    Sorry, "on"...I lost track of which way you wanted it.

    The only reason I mentioned network restarts is in case they ever get restarted w/o your say-so, but if you've tested it, then sounds like you're golden.

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •