12.4. Filtry mieszające i bardzo dużo szybkiego filtrowania

Jeśli potrzebujesz tysięcy reguł, na przykład w sytuacji gdy masz bardzo dużo klientów lub komputerów, dodatkowo różne specyfikacje co do `jakości usług' (ang. "Quality of Service", QoS) może się okazać, że twój kernel spędza bardzo dużo czasu sprawdzając te reguły.

Domyślnie, wszystkie reguły zapisane są w dużym łańcuchu, który sprawdzany jest w kolejności zmniejszających się priorytetów. Jeśli masz 1000 reguł, być może konieczne będzie 1000 testów by określić co zrobić z pakietem.

Sprawdzanie odbywałoby się szybciej, gdybyś miał 256 różnych łańcuchów i w każdym cztery reguły - jeśli podzieliłbyś pakiety pomiędzy te 256 łańcuchów, tak by reguły odpowiadały pakietom.

Tutaj przychodzi na pomoc mieszanie. Powiedzmy, że masz 1024 użytkowników w swojej sieci połączonych modemami kablowymi, z przydzielonymi adresami od 1.2.0.0 do 1.2.3.255. Każdy z nich należy do innej kategorii, np. `podstawowy', `standardowy' i `wyjątkowy'. Potrzebujesz 1024 reguł, takich jak te:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.1 classid 1:1
...
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.254 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.255 classid 1:2

By przyśpieszyć przetwarzanie, możemy użyć ostatniej części adresu IP jako `klucza mieszającego'. Dostajemy 256 tabel, z których pierwsze wyglądają tak:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.1.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.2.0 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.0 classid 1:2

Następna zaś zaczyna się tak:

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.1 classid 1:1
...

W ten sposób mamy tylko cztery testy w najgorszym wypadku a średnio dwa.

Konfiguracja jest trochę skomplikowana, ale warta czasu który zyskasz. Najpierw tworzymy filtr-korzeń a następnie tabelę z 256 wpisami:

# tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32
# tc filter add dev eth1 parent 1:0 prio 5 handle 2: protocol ip u32 divisor 256

Teraz dodajemy trochę reguł do wpisów w tabeli:

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.0.123 flowid 1:1
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.1.123 flowid 1:2
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.3.123 flowid 1:3
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.4.123 flowid 1:2

Mamy tu wpisy dla 123, które zawiera testy dla 1.2.0.123, 1.2.1.123, 1.2.2.123 oraz dla 1.2.3.123. Wysyła je do kolejek odpowiednio 1:1, 1:2, 1:3 i 1:2. Zauważ, że wartość mieszającą podajemy w wartościach heksdecymalnych, tutaj 0x7b to właśnie 123.

Teraz tworzymy `filtr mieszający', który kieruje ruch do właściwego wpisu w tabeli:

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \
        match ip src 1.2.0.0/16 \
        hashkey mask 0x000000ff at 12 \
        link 2:

Parę wartości może wymagać wyjaśnienia. Domyślna tablica mieszająca nazywa się 800:: i całe filtrowanie zaczyna się od niej. Wybieramy adres źródłowy, który znajduje się na pozycji 12, 13, 14 i 15 w nagłówku IP i wskazujemy, że jesteśmy zainteresowani tylko tą częścią ostatnią. Następnie wysyłamy go do tablicy mieszającej 2:, którą stworzyliśmy poprzednio

Trochę to skomplikowane, ale działa w praktyce a zysk wydajności będzie naprawdę uderzający. Zauważ, że ten przykład może być jeszcze polepszony, w idealnym przypadku każdy łańcuch zawierałby 1 filtr!.