lstewart abandoned this revision. lstewart added a comment. Hans,
Just because some hardware is capable of coalescing more than 64k of data doesn't mean we should feel obligated to support the functionality. I'd be curious to understand the anticipated use cases that led to hardware support being added. Without some compelling data to show that this is useful, I think this work should be put on ice until such time as it can be shown to be worthwhile. If such data exists, I'm willing to give it due consideration and revise my judgment, but at this stage I strongly suspect there is no workload we support or will support in the near future that would significantly benefit from raising the LRO chunk size above 64k vs the hacks required to make it work, so that's why I'm voting against this patch outright rather than suggesting changes. The real goal is to remove LRO entirely anyway, which I believe we have ideas on how to do e.g. packet batching techniques. As an aside, it would be useful to socialise ideas like this a bit more along with good data before investing the time and energy into doing the work unless it's trivial enough that it doesn't matter. Ideally we should have had this discussion on the mailing list centered around proposed use case(s) and a data set showing the limitations of the 64k limit on those use cases before the patch was proposed. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1761 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, rwatson, bz, imp, np, jfv, adrian, lstewart Cc: imp, freebsd-net-list _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
