[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201002042015.51092.opurdila@ixiacom.com>
Date: Thu, 4 Feb 2010 20:15:51 +0200
From: Octavian Purdila <opurdila@...acom.com>
To: David Miller <davem@...emloft.net>
Cc: amwang@...hat.com, linux-kernel@...r.kernel.org,
eric.dumazet@...il.com, linux-rdma@...r.kernel.org,
netdev@...r.kernel.org, nhorman@...driver.com,
linux-sctp@...r.kernel.org
Subject: Re: [RFC Patch] net: reserve ports for applications using fixed port numbers
On Thursday 04 February 2010 19:41:10 you wrote:
> From: Octavian Purdila <opurdila@...acom.com>
> Date: Thu, 4 Feb 2010 14:44:01 +0200
>
> > My concern is that we can have multiple applications that require a
> > fixed port and if those ports are significantly apart we will
> > decrease the port range available for connect. And that will hurt
> > the rate of which new connections can be opened.
>
> I'm already uneasy about adding the simple check every time
> we loop around in the bind port allocator.
>
> Adding an LSM hook to this spot? I absolutely refuse to allow
> that, it will completely kill bind performance.
>
I think Tetsuo was proposing the LSM hook, so I'll leave him the daunting task
of convincing you of the benefit of that :) - I have no opinion on this due to
massive lack of knowledge.
I was just proposing to use a discrete set of ports instead of a range. The
check in the current patch:
int inet_is_reserved_local_port(int port)
{
int min, max;
inet_get_local_reserved_ports(&min, &max);
if (min && max)
return (port >= min && port <= max);
return 0;
}
would become:
int inet_is_reserved_local_port(int port)
{
if (test_bit(port, reserved_ports))
return 1;
return 0;
}
In theory it might be slower because of the reserved_ports bitmap will have a
larger memory footprint than just a min/max, especially with random port
allocation. But is this an issue in practice?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists