LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [LVS - NAT] alternatives

To: Roberto Nibali <ratz@xxxxxx>
Subject: Re: [LVS - NAT] alternatives
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 12 Sep 2001 12:28:08 +0300 (EEST)
        Hello,

On Wed, 12 Sep 2001, Roberto Nibali wrote:

> Hello Julian,
>
> >         I think, I found a NAT problem in LVS for 2.4 when
> > the net driver support hardware checksuming but it seems it is
>
> How can HW checksumming interfere with NAT? Could you point me
> to the essential code in the kernel so I can follow you? :)

        For TUN we set skb->ip_summed to CHECKSUM_NONE after the
packet is changed and it indicates to the output functions that
this paacket does not have checksum calculated. The same is missing
for NAT in both directions.

        What I don't understand is why we have checksum error before
that point. Jeremy still didn't responded and I don't know whether
his chip has raw support for rx checksuming or whether the e100
driver performs checksuming in the CPU instead in the chip for
his card. So, any feedback from users using checksuming on chip
will be appreaciated. I need a possitive advice that LVS is working
with other drivers (may be after the LVS NAT is fixed).

> > at another place. The difference between the e100 driver and the
> > normal kernel driver is that e100 supports hardware checksuming.
>
> Yep, seen that. I haven't studied the e100 from Intel but I worked
> a little bit on the tweaking of the eepro100 and honestly I hardly
> ever experienced problems.

        E100 may be works with the TCP/IP stack in 2.4.4+ because
this driver does not register the devices for all capabilities, i.e.
in dev->features (you can see in other drivers this). But for now
I mostly suspect LVS.

> The general approach is:
>
>     1. Never use vendor drivers if there are in-kernel drivers
>     2. Use the kernel drivers and if they don't work,
>     3. Check out ftp://scyld.com/pub/network/ for eventual updates
>     4. If it still doesn't work, enable debugging mode and send
>        loginfo to Mr. Becker or the maintainer listed in the c-header
>     5. This worked in 99.99% of all cases for me. I almost never
>        experienced problems with NIC drivers where I had to patch
>        something.
>
> >         Are there other LVS users that have NAT problems in latest
> > 2.4 kernels when the rx checksuming is in effect? For example, 3com
>
> I don't know, reading the IIIC and IIID section of eepro100.c doesn't
> indicate any hardware based RX checksumming. AFAICS he uses the skbuff
> rx copybreak scheme which is not related to LVS if I read the kernel
> code path correctly.

        XsumRX

        I remember that some drivers were fixed recently in
the kernel, they didn't calculated correctly the checksum but this
is another issue.

> > cards? The effect is that LVS reports incoming or outgoing TCP checksum
> > failures. For now, I'm not sure who to suspect, may be these drivers do
>
> Increase the ringbuffer sizes. People having problems show maybe send in
> a ``ip -s -s link show dev eth0''. Sometimes I could minimize IRQ over-
> head by setting a higher tx queue lenght for the link:
> ``ip link set eth0 txqueuelen 500''. I don't know if this is honoured by
> all NIC drivers, and I honestly haven't checked the code either.

        Not sure. But consider this fact: this NIC and this driver
work for non-LVS traffic.

> > wrong checksum calcs not in the chip and report CHECKSUM_HW. We will
>
> You mean in speedo_rx(): before skb queuing?

        Grr, this is in e100, not in the kernel driver, I'm refering
to e100_calculate_checksum in e100-1.6.13.tar.gz

> > see what Jeremy will report for the patch I sent him yesterday.
>
> I'm curious, what patch? [gimme, gimme, gimme the patch :)] Is it based
> on the vanilla kernel eepro100.c or the newest scyld driver (which is
> completely different to the kernel one, as I can see now)

        This patch is for LVS and is at home. But I can try to build it
again for you, if you have cards with hardware checksuming support :)
OK, appended.

> Hey, you can always set: skb->ip_summed = CHECKSUM_UNNECESSARY ;)

        Or better CHECKSUM_NONE, used in the output functions

> Cheers,
> Roberto Nibali, ratz


Regards

--
Julian Anastasov <ja@xxxxxx>


--- ipvs-0.9.3/ipvs/ip_vs_conn.c.orig   Mon Aug 27 05:40:54 2001
+++ ipvs-0.9.3/ipvs/ip_vs_conn.c        Wed Sep 12 12:15:57 2001
@@ -783,6 +783,7 @@
                break;
        }
        ip_send_check(iph);
+       skb->ip_summed = CHECKSUM_NONE;

        IP_VS_DBG(10, "NAT to %u.%u.%u.%u:%d\n",
                  NIPQUAD(iph->daddr), ntohs(h.portp[1]));
--- ipvs-0.9.3/ipvs/ip_vs_core.c.orig   Mon Aug 27 05:40:54 2001
+++ ipvs-0.9.3/ipvs/ip_vs_core.c        Wed Sep 12 12:16:29 2001
@@ -841,6 +841,7 @@
                break;
        }
        ip_send_check(iph);
+       skb->ip_summed = CHECKSUM_NONE;

        ip_vs_out_stats(cp, skb);
        ip_vs_set_state(cp, VS_STATE_OUTPUT, iph, h.portp);



<Prev in Thread] Current Thread [Next in Thread>