[GTER] RES: RX Pause em GE CCR1036 vs. 3c2920.

[Shine]

Henrique,

Eu acredito que usar flow em uma rede camada 3 não traz nenhum benefício,
nisso concordamos.
Também acredito que usar o flow control sem ter nenhum motivo específico
não é recomendável. Você adiciona um parâmetro a mais para depurar e isso
acaba dificultando a operação.

Apenas como adendo e para completar sua recomendação, existem casos onde o
flow control é necessário. FCoE por exemplo (acho que é o único caso onde
eu vejo um uso efetivo do flow control...). E aí não dá para falar em
desligar o flow control.


Em 8 de maio de 2014 16:38, Henrique de Moraes Holschuh
<hmh at hmh.eng.br>escreveu:

> On Wed, 07 May 2014, Douglas Fischer wrote:
> > P.S.: Na verdade eu só ví isso em FC, principalmente em switchs meia boca
> > onde depois de um agregation o enlace seguinte tenha algum
> oversubscription.
>
> Flow-control é gerador de pesadelo de administrador de rede, simples assim.
> Basta ter uma LAN com grande potencial de contenção nos uplinks/troncos, e
> switches que preferem propagar pause-frame a perder pacote.
>
> Aliás, leia isso para uma história de horror regada à flow-control:
>
>
> http://monolight.cc/2011/08/flow-control-flaw-in-broadcom-bcm5709-nics-and-bcm56xxx-switches/
>
> BCM56xxx são os famosos StrataXGS.  Tem isso dentro de tudo quanto é switch
> gigabit gerenciável dos mais variados fabricantes...
>
> > Mas o que eu quis dizer é que se existe algum problema que só ocorra
> quando
> > em LAG, em não em interface única... Talvez o problema não esteja no
> > aggregation. Talvez o aggregation esteja apenas explicitando a existência
> > desse problema.
>
> Um pause-frame recebido na hora errada pode segurar os frames de controle
> (BPDUs, LACP, etc) no TX-ring/packet-buffer.  É bem fácil de imaginar que
> isso pode exarcebar problemas.
>
> > Não escondo meus receios sobre MK, mas nesse caso o design do MK é menos
> > problemático no que se refere a buffers.
>
> O que conta é o tamanho do RX-ring, porque qualquer NIC que preste vai
> emitir pause-frames automaticamente (em hardware/firmware) quando o RX-ring
> estiver quase cheio se o flow-control para aquela direção estiver ligado.
>
> Exceção para portas em network processors ou ASICs, que podem ou não ter
> algo diferente por trás do sistema de flow-control, mas não é o caso da
> maior parte dos MKs (talvez seja caso na CCR).
>
> De qualquer forma, o MK muito provavelmente[1] vai honrar os pause-frames
> recebidos (ou seja, emitidos pela switch) sem distinção do que estiver no
> TX-ring e outgoing queues, e aí pode estar o problema.
>
> Para piorar, que eu saiba em geral Linux não conta pause-frames.  Eles vão
> aparecer, *talvez*, no contador de frames multicast (e isso depende do
> NIC/driver).  Certamente não achei nos "performance counters" do ethtool,
> que são a base do monitoramento SNMP.  Então ou vê que tem coisa errada
> pelos contadores da switch, ou não fica nem sabendo...
>
> [1] leia-se: sempre que for Linux controlando a porta/NIC
>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>