Enable hardware transmit TCP resegmentation

cbaker_at_GOODYEAR.COM
Date: 04/22/04

  • Next message: Holger.VanKoll_at_SWISSCOM.COM: "Re: Enable hardware transmit TCP resegmentation" 
    Date:         Thu, 22 Apr 2004 13:50:31 -0400
To: aix-l@Princeton.EDU

    Jason,

    Noticed in your reply below that you had a problem with Veritas Netbackup and Gigabit ethernet on an IBM server.

    We had the same problem late last year. We did not have to put a fix on, but rather we had to turn off "Enable hardware transmit TCP
    resegmentation" on the gigabit card. Please see part of note I sent last year that explains. Perhaps you had this turned off and
    putting the APAR on turned it back on?

       Supposedly, when large data is moved over the Gigabit ethernet card and support is turned ON for "Hardware Offload of TCP
       Resegmentation", Netbackup can get the box in a hung state. Have not found that any other "data mover" will hang the box, but
       looking at the clipping below, it can cause degraded network throughput. Maybe NetBackup is more aggressive?

       I have DISABLED this setting on the NFS servers as follows:

          ifconfig en2 down detach
          ifconfig et2 down detach
          chdev -l ent2 -a large_send=no
          mkdev -l en2
          mkdev -l inet0

             - or -

          "smitty chgenet" and change the "Enable hardware transmit TCP resegmentation" to NO

       Here is one clipping I found on IBM site that explains how HW transmit TCP reseg works and how it can hurt:

          TCP/IP now supports hardware offload of TCP resegmentation for transmitted TCP segments in conjunction with the Gigabit
          Ethernet-SX PCI Adapter and IBM 10/100/1000 Base-T Ethernet PCI Adapter. This capability is enabled using an additional SMIT
          adapter configuration menu option, titled "Enable hardware transmit TCP resegmentation". The default value for this option is
          "no", but can be enabled by the user. This feature allows TCP to send a large TCP segment (up to 64K bytes) to the adapter and
          the adapter will then resegment this buffer into smaller 1500 byte packets to be sent on the Ethernet network.
          This reduces the AIX system overhead which lowers the CPU utilization, and releases CPU cycles to be used for other work by the
          server. However, the adapter must now resegment the buffer and recompute the TCP checksums, which typically reduces the raw
          throughput on each adapter. In laboratory measurements, system CPU utilization has been observed to drop by 10% to 60% while the
          raw throughput may degrade by 10% to 30% (these numbers will vary by workload). However, the raw throughput may increase when
          using multiple adapters by as much as 25%. This feature is not for all workloads but should be evaluated when there is a need to
          reduce server CPU utilization and is most useful when the server sends more data than it receives.

    Hope that helps you or anyone else seeing slowness on gigabit cards when running Veritas backup products.

    Christopher M. Baker
    Senior Technical Support Analyst
    DSE/TCO
    Goodyear Tire and Rubber Company

    =================================================
    Contains Confidential and/or Proprietary Information.
    May not be copied or disseminated without the expressed
    written consent of The Goodyear Tire & Rubber Company.
    =================================================

                          Jason delaFuente
                          <jason.delafuent To: aix-l@Princeton.EDU
                          e@GBE.COM> cc: (bcc: Chris Baker/NA/GDYR)
                          Sent by: IBM AIX Subject: Re: Impact of APAR
                          Discussion List
                          <aix-l@Princeton
                          .EDU>

                          04/22/04 01:04
                          PM
                          Please respond
                          to IBM AIX
                          Discussion List

    You can look into what specific filesets are part of the APAR. As a rule we have a sandbox, dev, qa, training, and production
    environment. Fixes are rolled out in that order so that if a problem does occur it is recognized early on before it is to visible.
    We also always install in APPLIED mode so that it can be backed out quickly. In the past month we had an issue where the installation
    of a particular 5.2 APAR caused our Veritas backups through the gigabit ethernet interface to slow to a crawl. We were able to quickly
    back out and the impact was minimal. We eventually resolved it and started the rollout again.

    Unless a specific problem in our environment is identified along with an APAR that corrects the problem we usually just install fixes
    with a whole maintenance level install.

    Jason de la Fuente

    >>> Praveen.Kumar@CAHOOT.COM 04/22/04 11:29AM >>>
    Hi *,
              Can someone give me a view of hoe to analyse the impact of an APAR
    that would be applied on a system. I understand that this differs from each
    application that is running on the server. But in general how do we start
    analysing the impact, it would be great if someone can share any of the
    existing check lists which you use.

    TIA
    Praveen.K

    *********************
    Internet communications are not necessarily secure and may be intercepted or
    changed after they are sent. cahoot does not accept liability for any such
    changes.
    If you wish to confirm the origin or content of this communication, please
    contact the sender using an alternative means of communication.

    This communication does not create or modify any contract.

    This email may contain confidential information intended solely for use by
    the addressee. If you are not the intended recipient of this communication
    you should destroy it without copying, disclosing or otherwise using its
    contents.

    Please notify the sender immediately of the error.

    cahoot is a division of Abbey National plc.
    Abbey National plc is registered in England, registered number 2294747.
    Registered Office: Abbey National House, 2 Triton Square, Regent's Place,
    London, NW1 3AN.

  • Next message: Holger.VanKoll_at_SWISSCOM.COM: "Re: Enable hardware transmit TCP resegmentation"