Димон включил самого себя. А потому шо самый строгий метод хеширования в протоколе 802.3ad - src_dst_port - использует, увы номера портов источника и назначения. Один поток пойдет по одному физ адаптеру. Режим round-robin коммутаторы на практике не поддерживают. Конечно ТС ничего не написал про коммутаторы но судя по его замашкам, ему надо кроссплатформенное и кроссхардловое, ну оставим его восвояси. Я поставил абсолютно конкретную задачу: линк сервер-сервер, 1 тцп поток, нужно скорость 2G.
Eyeland ее решил. Дмитрий - нет. Так и запишем. Не знает, не разобрался, непрофессионал. Стыдно, Дмитрий, почему я, непрофессионал, знаю такие вещи? Чему вы учите детей в университете? Мне страшно, я не хочу, чтобы мои дети учились на вашей кафедре. Ваше поведение свидетельствует о неполном служебном соответствии. Я вас больше по этому поводу задрачивать не буду, но советую впредь задумываться над своими необоснованными репликами, для вашей же пользы.
Витек, вы попросили мой конфиг. Я его привел. Да это конфиг для решения задачи построения LACP Linux-Extreme. Хеш считается по приведенной мной выше формуле
.
1-н TCP поток вы себе сами нафантазировали. Я спросил ТС подойдет ли ему хеширование на L4. Вы утверждали что таковое вообще не возможно.
ни один протокол агрегации не анализирует глубже IP
Возможно, собственно этот конфиг опровергает вашу ахинею. Хотите rr Linux-Linuх (я не вижу в этом практической значимости), ставьте mode=0, как писал Eyeland, что так сложно? У меня нет такой тестовой платформы на 4Г. Персонально для вас я ее собирать не намерен. На 2Г с rr отлично работает.
Ну а теперь приведите ваш конфиг для FreeBSD-Extreme на основе ng_one2many

И вообще, вам тут уже привели два конфига, один Eyeland (Linux-Linux), второй я (Linux-Extreme). А вы пока только пустозвоните и проповедуете
проприетарные дилетантские, не маштабируемые и потенциально проблемные решения. Или мне уже конфиг "LACP" FreeBSD-FreeBSD за вас писать?
а в такой связке 1 тцп это 1Ж не более.
для ТС надо mode=0, но будет ли корректно работать...
судя то посту ТС -нет
В первом посте идет речь об nfs, nfs на транспортном уровне как правило использует UDP, в этом случае да, rr (mode=0) + JumboFrames 9к будет корректно работать. В случае использования TCP, да rr (mode=0) + JumboFrames 9к будет корректно работать и равномерно загружать оба линка. А теперь, приведите ваш конфиг!
Это я уже не говорю про эту ахинею:
индифферентно, что ethernet кадры рвутся
И о том, что вы плаваете в терминах. Пока Витя слабенько, очень слабенько.