[replicant]

Это решение справедливо для случая igb + igb и использования двухголовой карты ?

Да, для любого случая (прогнал на двух igb устройствах, на двухголовой и на четырехголовой). Выключать gro на всех igb устройствах.

Изменено 22 ноября, 2010 пользователем replicant

[photon]

Это решение справедливо для случая igb + igb и использования двухголовой карты ?

Да, для любого случая (прогнал на двух igb устройствах, на двухголовой и на четырехголовой). Выключать gro на всех igb устройствах.

В любом случае, следует уведомить разработчиков об этом через багзиллу, чтобы в следующих ядрах по крайней мере выключили GRO по умолчанию.

[SokolovS]

Да вобще весь оффлоад нужно выключать, на транзитный трафик он влияния не оказывает.

[vitalyb]

кроме checksumming, разумеется - этот оказывает, еще и как. scatter-gather тоже вредить не должен, но может сэкономить где-нибуть memcpy()

 

Но феномен интересный. Неужели сетевой адаптер пытается каждый tcp flow разобрать и сложить отдельно большими пакетами?..

 

[replicant]

Да вобще весь оффлоад нужно выключать, на транзитный трафик он влияния не оказывает.

Вот если бы не оказывал, то не было бы и проблем с транзитным трафиком и шейпером. По поводу выключения rx / tx я в больших сомнениях. Все отключать я бы не стал.

 

Неужели сетевой адаптер пытается каждый tcp flow разобрать и сложить отдельно большими пакетами?..

Ага. Именно это он и делает.

[Alex780]

2.6.36

Offload parameters for eth1:

rx-checksumming: on

tx-checksumming: off

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off

все работает при включенном даже.. шейпер на базе htb

 

отключить не получается

ethtool -K eth0 generic-receive-offload off

no offload settings changed

 

[Max P]

попробуйте так - ethtool -K eth0 gro off

[Alex780]

да, так выключилось. Посмотрим что изменилось

[replicant]

2.6.36

tx-checksumming: off

generic-receive-offload: on

large-receive-offload: off

все работает при включенном даже.. шейпер на базе htb

А какие там у вас стоят сетевые карточки? Выдайте на осмотр ethtool -i ethX по всем интерфейсам. С выключенным tx-checksumming проблем не возникает?

Изменено 23 ноября, 2010 пользователем replicant

[Alex780]

драйвер который шел с ядром:

driver: igb

version: 2.1.0-k2

firmware-version: 1.2-1

 

карта интеловая двухпортовая оптическая

01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

 

проблем при таких настройках не замечаю, в чем они у вас заключаются? сейчас выключил gro эффекта тоже не вижу.. может плохо смотрю? шейпер режет, траф проходит через два эти интерфейса, ospf через quagga c бордером, с другой стороны каталист. Траф до 700М

[replicant]

драйвер который шел с ядром:

driver: igb

version: 2.1.0-k2

firmware-version: 1.2-1

 

карта интеловая двухпортовая оптическая

01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

 

проблем при таких настройках не замечаю, в чем они у вас заключаются? сейчас выключил gro эффекта тоже не вижу.. может плохо смотрю? шейпер режет, траф проходит через два эти интерфейса, ospf через quagga c бордером, с другой стороны каталист. Траф до 700М

Дело либо в ядре 2.6.36 либо в оптической карте, потому что на "медных" картах проблемы были с шейпированием и полисингом трафика на PPP интерфейсах. Решились только отключением gro. У вас сколько PPTP соединений на сервер генерируют такой трафик в 700 Мбит/с? Если у вас там нет PPTP, то понятно почему работает (без PPTP оно и работало). Эффект именно в том случае, когда сервер PPTP + TC + SNAT(DNAT) оснащен такими картами на выходе и входе.

 

Я вот тут рисовал схему для теста.

 

Хотелось бы глянуть на pstree с вашей машины, если это не сложно.

Изменено 23 ноября, 2010 пользователем replicant

[Alex780]

никакого pptp и ната нет, трафик проходящий. Схему не смотрел, так что сорри, видать простой не тот случай как у вас

 

init─┬─abrtd

├─acpid

├─auditd───{auditd}

├─crond

├─dbus-daemon

├─gpm

├─6*[mingetty]

├─ospfd

├─rsyslogd───2*[{rsyslogd}]

├─2*[sendmail]

├─sshd─┬─sshd───bash───mc───bash───7*[tc-view-user]

│ └─sshd───sshd───bash───su───bash───mc───bash───pstree

├─udevd───2*[udevd]

├─xinetd

└─zebra

 

[replicant]

Alex780, у вас точно не такой случай. В вашем случае поводов для беспокойства вообще нет.

[vitalyb]

Похоже, в случае с pptp трафик перестает быть транзитным для ОС и она пытается его offload'ить. Может где-то есть "секретный" флаг для сокета/skb, чтобы этого не происходило?

[Ivan_83]

Похоже, в случае с pptp трафик перестает быть транзитным для ОС и она пытается его offload'ить. Может где-то есть "секретный" флаг для сокета/skb, чтобы этого не происходило?

Странные вы люди.

Делайтесь прозрачным мостом для пптп и тогда он останется транзитным.

 

А так, ОС нужно вытащить упакованный IP из пптп и запихать его в эзернет, как правило, естественно приходится все суммы пересчитывать и пакет пересобирать.

[vitalyb]

Делайтесь прозрачным мостом для пптп и тогда он останется транзитным.

 

А так, ОС нужно вытащить упакованный IP из пптп и запихать его в эзернет, как правило, естественно приходится все суммы пересчитывать и пакет пересобирать.

и чем же пптп отличается от "вытащить ip из ethernet, поменять ttl, запаковать в другой ethernet", попутно "пересчитывая все суммы"?

[Max P]

делать транзитный шейпер для пптп? интересный случай

[vinnipux]

Кажется нашел что влияло. На одной из сборок не подтвердился глюк шейпера. Сейчас найду отличия, но, если мне не изменяет память то это GRO (LRO) в ядре.

 

Сетевые e1000e и tg3 этого просто не понимают по-умолчанию, а igb понимает, но реализация этого влияет на шейпер транзитного трафика. Сейчас тесты провожу.

Судя по результатам моего тестирования, уважаемый replicant, Вы правы !!! За что вам большущее спасибо !!! ))

Кстати а у e1000e GRO отключено по умолчанию, хотя я тоже думаю, что это обусловлено возможностями чипа.

 

[SokolovS]

кроме checksumming, разумеется - этот оказывает, еще и как. scatter-gather тоже вредить не должен, но может сэкономить где-нибуть memcpy()

Ну так я и написал что отключать нужно только offload, для транзита не суть важно.

[replicant]

Кстати а у e1000e GRO отключено по умолчанию, хотя я тоже думаю, что это обусловлено возможностями чипа.

Там по-умолчанию отключено, потому что возможности чипа не те, поэтому и проблема не вылезала.

 

 

Делайтесь прозрачным мостом для пптп и тогда он останется транзитным.

2 Ivan_83, подскажите в двух словах как это реализовывается для случая с сетью приватных IP, хотя подозреваю что не важно какие адреса в сети, но все же, как?

 

Ну так я и написал что отключать нужно только offload, для транзита не суть важно.

А вот ethtool считает относящимися к offload следующие параметры.

ethtool -K|--offload DEVNAME Set protocol offload

[ rx on|off ] [ tx on|off ] [ sg on|off ] [ tso on|off ] [ ufo on|off ] [ gso on|off ] [ gro on|off ] [ lro on|off ]

Я тоже так считаю, хотя это уже не так важно, потому что вопрос решен.