Hello,
On Wed, 18 Sep 2002, Roberto Nibali wrote:
> > - if netfilter connection tracking is used, ip_send_check is called
> > after ip_defrag and LVS has packet with valid IP csum.
>
> Hey, I think with the new {nf|ct}-netlink framework you could ask for
> that and then do your conditional check. But I doubt if it will be
> faster then.
We can now use one ip_send_check at the beginning of ip_vs_in(),
it will delay only NAT because this is the only method that
uses its own ip_send_check after header change. IMO, the best thing
is when after each ip_defrag there is ip_send_check. But it
is better if IPVS is out of LOCAL_IN which will not happen
soon.
> > Now, after introducing the Layer 8 factor (Julian) who
>
> LOL! Maybe someone should update some RFC with OSI-L8 then :).
Agreed :)
> > So, we add unconditional ip_send_check when we know the
> > packet will be forwarded to another host. We can not know that
> > someone fixed the csum after ip_defrag.
>
> 2 Questions:
>
> o Wouldn't it be nicer to have a bitfield in the struct skbuff which
> indicates the csum status? But I guess then netfilter would need to
> adapt a lot of code. But I see some nice unused fields in skbuff :)
NFC_NEED_IPCSUM :)
> o Shouldn't we do a conditional check for skb->summed? For example if it
> is for the LOCAL_NODE feature.
Yes, local node and NAT don't need this csum update, the
csum2 patch accounts it.
> We should really put the LVS hook out of the netfilter misery and call
> it directly from the FIB :)
To control routing :) It is difficult :) But it is possible
to link one conn entry for the both directions and calling
routing with different keys (working at prerouting), NAT on FORWARD :)
Then we can work with many ISPs :) SNAT decision before routing
or more correctly, with lsrc key for established traffic. One
day I'll try it for test.
> BTW, Julian, do you know how to export a struct to the slabinfo so it
> doesn't show up in on of the size-{32,64,...} slabs? If I have multiple
> size-128 slabs, I would like to differentiate them. For example like
> arp_cache or skbuff_head_cache.
Hm, I only know for slab cache, if you have many size-128
entries you better to use cache. Or you have something different
in mind?
> Best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|