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;-) _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
