From owner-svn-src-all@freebsd.org Thu Jul 5 21:14:41 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99A991031B7B; Thu, 5 Jul 2018 21:14:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660083.outbound.protection.outlook.com [40.107.66.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 261EF76C82; Thu, 5 Jul 2018 21:14:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB1787.CANPRD01.PROD.OUTLOOK.COM (52.132.44.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Thu, 5 Jul 2018 21:14:39 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::7098:a543:5be8:f30e]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::7098:a543:5be8:f30e%4]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 21:14:39 +0000 From: Rick Macklem To: Andrew Gallatin , "rgrimes@freebsd.org" CC: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r335967 - head/sys/dev/mxge Thread-Topic: svn commit: r335967 - head/sys/dev/mxge Thread-Index: AQHUE/r/U9IY4eihoEW9Zacqgo0Qe6R/1L2AgAAUUoCAATWlZw== Date: Thu, 5 Jul 2018 21:14:39 +0000 Message-ID: References: <201807050120.w651KP5K045633@pdx.rh.CN85.dnsmgr.net>, <97ae3381-7c25-7b41-9670-84b825722f52@cs.duke.edu> In-Reply-To: <97ae3381-7c25-7b41-9670-84b825722f52@cs.duke.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1787; 7:T9QDR2/7hfMqjD34muyRs7FXwe7DH3y8DrRgQlYmCU0HjqshTuhfjD8jmjEKNc4CPNiIgjrCHX33kN9GeC7kBbcPMhonvW1ZPxkMnFJa5aGkogKG7R+C0YXiaYyrfGKJEeLH2bk3FdQJrQgCpHJP8eUCO2Y9ExX3uIL3KNbWcSWoFvsFt1anF7xRYSect1klbCGnvZP0uiSjb9+qmn78lX6yhxae8zmD0l+Pc/XXsula8a5BD5Gp+2X9pca+luBh x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0d761224-3d77-4882-0b34-08d5e2bc51d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1787; x-ms-traffictypediagnostic: YTOPR0101MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1787; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1787; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(136003)(39860400002)(199004)(189003)(476003)(68736007)(99286004)(486006)(4326008)(446003)(11346002)(6506007)(53546011)(106356001)(45080400002)(2501003)(55016002)(105586002)(86362001)(74316002)(9686003)(2906002)(305945005)(5660300001)(14444005)(256004)(2171002)(74482002)(6246003)(53936002)(110136005)(316002)(54906003)(26005)(786003)(97736004)(8936002)(186003)(33656002)(478600001)(25786009)(229853002)(6436002)(102836004)(5250100002)(2900100001)(81166006)(7696005)(81156014)(76176011)(14454004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1787; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: GBGSavHlhZDsvBfEjfGs0TyenOkjohOZb6KTYvH9ofUH+rF/mM6w7z++0LBJ3nx0KuM1IuGyukH8tei4Yvg4iJdZcZLNJBYABv9YH3dk+wb4ZrDs+pZS0TUnEVbsS7k2+rbBl+712TxeUgwcEDC9uhDvSPJKIf9LYOZGSyxL/HwS6VzlH8kOB6PeoN/TL1T1rmEf8jQ6YbV+S85XorGoWDvqp5f/Pw0TJ/DCwe3qcdEYSqzirA8g75NWD63u//1mDKkOOMb6DFRQjRB+TjG6nJcsc339vbSQM/yJ226MWbxo+LQfEJlqr5ptKji+YBUZFwf3GPUFwXOKgSk6mjS33+d2IacQ7tT/cWpyfGE8qME= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 0d761224-3d77-4882-0b34-08d5e2bc51d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 21:14:39.7035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1787 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 21:14:41 -0000 Andrew Gallatin wrote: On 7/4/18 9:20 PM, Rodney W. Grimes wrote: [stuff snipped] >> >> It is using a magic constant twice, where one has a >> derived value that is dependent on the value of the other. >> That is bad and error prone and does not document that >> one depends on the other. Please fix this. Or at least >> make 65536 a #define so that it only needs changed one >> place and clearly shows the interdependence of these >> values. > >To me, 65536 is one of the few cases where the magic number is >more meaningful than a name. But fine, if you feel that >strongly about it, I'll change it for you. Btw, in general, if_hw_tsomax and if_hw_tsomaxsegsize are not related or the same value. It just happens that they both appear to be related to 64K in this case. (I believe this is fairly common, since the original Microsoft "standard" used 64K as a limit, since it was stored in 16bits.) if_hw_tsomax is the maximum size of the entire TSO segment, including MAC level headers (commonly 64K, due to Mircosoft... but could be larger if the hardware guys chose to do so). if_hw_tsomaxsegsize is the maximum size of contiguous memory that a "chunk" of the TSO segment can be stored in for handling by the driver's transmit side. Since higher level code such as NFS (and iSCSI, I think?) uses MCLBYTE clusters, anything 2K or higher normally works the same. Not sure about sosend(), but I think it also copies the data into MCLBYTE clusters? This would change if someday jumbo mbuf clusters become the norm. (I tried changing the NFS code to use jumbo clusters, but it would result in fragmentation of the memory used for mbuf cluster allocation, so I never committed it.) rick ps: And I'll admit I don't find 65536 very magic;-)