On 01/22/2014 04:11 PM, Dan Ballard wrote:
Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
gets a socket specific max datagram queue length. Currently each socket
has one but it's only ever initialized from
/proc/sys/net/unix/max_dgram_qlen and then never adjustable later
On Wed, Jan 22, 2014 at 04:20:36PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Jan 22, 2014 at 07:11:20AM -0800, Dan Ballard wrote:
> > diff --git a/net/core/sock.c b/net/core/sock.c
> > index 5393b4b..1ff69d1 100644
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -915,6 +915,10 @@
On Wed, 2014-01-22 at 07:11 -0800, Dan Ballard wrote:
> Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
> gets a socket specific max datagram queue length. Currently each socket
> has one but it's only ever initialized from
> /proc/sys/net/unix/max_dgram_qlen an
On Wed, Jan 22, 2014 at 07:11:20AM -0800, Dan Ballard wrote:
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 5393b4b..1ff69d1 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -915,6 +915,10 @@ set_rcvbuf:
> sk->sk_max_pacing_rate);
>
Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
gets a socket specific max datagram queue length. Currently each socket
has one but it's only ever initialized from
/proc/sys/net/unix/max_dgram_qlen and then never adjustable later. Now
each socket can have it individually
Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
gets a socket specific max datagram queue length. Currently each socket
has one but it's only ever initialized from
/proc/sys/net/unix/max_dgram_qlen and then never adjustable later. Now
each socket can have it individually
On Wed, Jan 22, 2014 at 07:11:20AM -0800, Dan Ballard wrote:
diff --git a/net/core/sock.c b/net/core/sock.c
index 5393b4b..1ff69d1 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -915,6 +915,10 @@ set_rcvbuf:
sk-sk_max_pacing_rate);
On Wed, 2014-01-22 at 07:11 -0800, Dan Ballard wrote:
Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
gets a socket specific max datagram queue length. Currently each socket
has one but it's only ever initialized from
/proc/sys/net/unix/max_dgram_qlen and then never
On Wed, Jan 22, 2014 at 04:20:36PM +0100, Hannes Frederic Sowa wrote:
On Wed, Jan 22, 2014 at 07:11:20AM -0800, Dan Ballard wrote:
diff --git a/net/core/sock.c b/net/core/sock.c
index 5393b4b..1ff69d1 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -915,6 +915,10 @@ set_rcvbuf:
On 01/22/2014 04:11 PM, Dan Ballard wrote:
Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and
gets a socket specific max datagram queue length. Currently each socket
has one but it's only ever initialized from
/proc/sys/net/unix/max_dgram_qlen and then never adjustable later
linux-os (Dick Johnson) wrote:
I seem to be running into a limit of 64 queued datagrams. This isn't a
data buffer size; varying the size of the datagram makes no difference
in the observed queue size. If more datagrams are sent before some are
read, they are silently dropped. (By "silently,"
On Tue, 9 Aug 2005, Jonathan Ellis wrote:
> (Posted a few days ago to c.os.l.networking; no replies there.)
>
> I seem to be running into a limit of 64 queued datagrams. This isn't a
> data buffer size; varying the size of the datagram makes no difference
> in the observed queue size. If more
(Posted a few days ago to c.os.l.networking; no replies there.)
I seem to be running into a limit of 64 queued datagrams. This isn't a
data buffer size; varying the size of the datagram makes no difference
in the observed queue size. If more datagrams are sent before some are
read, they are
(Posted a few days ago to c.os.l.networking; no replies there.)
I seem to be running into a limit of 64 queued datagrams. This isn't a
data buffer size; varying the size of the datagram makes no difference
in the observed queue size. If more datagrams are sent before some are
read, they are
On Tue, 9 Aug 2005, Jonathan Ellis wrote:
(Posted a few days ago to c.os.l.networking; no replies there.)
I seem to be running into a limit of 64 queued datagrams. This isn't a
data buffer size; varying the size of the datagram makes no difference
in the observed queue size. If more
linux-os (Dick Johnson) wrote:
I seem to be running into a limit of 64 queued datagrams. This isn't a
data buffer size; varying the size of the datagram makes no difference
in the observed queue size. If more datagrams are sent before some are
read, they are silently dropped. (By silently, I
16 matches
Mail list logo
