|
Hello,
On Sun, 2 Oct 2005, Wensong Zhang wrote:
> I agree to including this one-packet feature into kernel 2.6.15+.
Also, we should not sync these packets, there should be
check in ip_vs_in before calling ip_vs_sync_conn. But ops looks
valid only for DR/TUN setups, not for NAT, so better not to hurry
without checking everything. Nicolas, what is the used forwarding
method and are there any RADIUS replies?
> In the mean while, we probably need to make a framework for
> service-related features, so that more service related features can be
> added and enabled/disabled. For example, for UDP-based service, we can
> probably parse the content of payload and schedule packets according to
> the content, which may be used for load balancing UDP-based SIP service.
From some time we provide skb to all schedulers, so they can
even reallocate and linearize skb data but we should not do it,
there are ways for read-only access to payload.
As for SIP, i'm not sure. May be it should be a scheduler
module that has a table for hashed Call-IDs, it looks like it should
exploit per-packet scheduling but not exactly the one-packet
scheduling because for NAT setups the replies should be forwarded
back.
Also, it is not possible to route replies correctly,
_out_get can route back to client and may be that is enough but the
per-packet scheduling has one dangerous drawback: we end up with many
connections for one CIP:CPORT hashed in single chain. Our goal should
be to have 5 conns if this CIP:CPORT talks to 5 real servers.
So, i'm not sure how the in_get lookup can be combined
with per-packet scheduling logic without creating many CLIENT->VS->RS
connections. ip_vs_sync makes the problem more difficult, it does not
tolerate multiple connections with same CIP:CPORT to VS. May be we
can drop ops and replace it with smart per-packet scheduling that does
not create many connections. We will always hash conns but their number
will be reduced. User still can reduce UDP timeout to desired value.
May be there can be service flag that requests per-packet
scheduling but with reduced number of connections. The SIP scheduler
can request the same. This flag should be somehow propagated to
existing connections returned from _in_get to cause scheduling and
second conn lookup (may be out_get) that avoids duplicated connections
between CIP:CPORT and RS - little slower but avoids creating extra
connections.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
