On Fri, Dec 4, 2020 at 3:20 AM Edward Cree wrote:
>
> On 03/12/2020 19:52, John Ousterhout wrote:
> > Homa uses GRO to collect batches of packets for protocol processing,
> > but there are times when it wants to push a batch of packet up through
> > the stack immediately (
econds before
they are pushed up the stack. Homa is trying to squeeze out latency,
so the extra delay is undesirable.
-John-
On Thu, Dec 3, 2020 at 11:35 AM Eric Dumazet wrote:
>
>
>
> On 12/3/20 8:03 PM, John Ousterhout wrote:
> > I recently upgraded my kernel module
I recently upgraded my kernel module implementing the Homa transport
protocol from 4.15.18 to 5.4.80, and a GRO feature available in the
older version seems to have gone away in the newer version. In
particular, it used to be possible for a protocol's xxx_gro_receive
function to force a packet up t
On Tue, Oct 1, 2019 at 1:53 PM Eric Dumazet wrote:
>
> On 10/1/19 1:45 PM, John Ousterhout wrote:
>
> >
> > But this isn't really about socket resource limits (though that is
> > conflated in the implementation); it's about limiting the time spent
>
On Tue, Oct 1, 2019 at 11:34 AM Eric Dumazet wrote:
>
> On 10/1/19 10:25 AM, John Ousterhout wrote:
> > On Tue, Oct 1, 2019 at 9:19 AM Eric Dumazet wrote:
> >> ...
> >> Sorry, I have no idea what is the problem you see.
> >
> > OK, let me try again fro
On Tue, Oct 1, 2019 at 9:19 AM Eric Dumazet wrote:
> ...
> Sorry, I have no idea what is the problem you see.
OK, let me try again from the start. Consider two values:
* sk->sk_backlog.len
* The actual number of bytes in buffers in the current backlog list
Now consider a series of propositions:
On Mon, Sep 30, 2019 at 6:53 PM Eric Dumazet wrote:
>
> On 9/30/19 5:41 PM, John Ousterhout wrote:
> > On Mon, Sep 30, 2019 at 5:14 PM Eric Dumazet wrote:
> >>
> >> On 9/30/19 4:58 PM, John Ousterhout wrote:
> >>> As of 4.16.10, it appears to me that sk
(I accidentally dropped netdev on my earlier message... here is Eric's
response, which also didn't go to the group)
-- Forwarded message -
From: Eric Dumazet
Date: Mon, Sep 30, 2019 at 6:53 PM
Subject: Re: BUG: sk_backlog.len can overestimate
To: John Ousterhout
On 9/
On Mon, Sep 30, 2019 at 5:14 PM Eric Dumazet wrote:
>
> On 9/30/19 4:58 PM, John Ousterhout wrote:
> > As of 4.16.10, it appears to me that sk->sk_backlog_len does not
> > provide an accurate estimate of backlog length; this reduces the
> > usefulness of the "l
As of 4.16.10, it appears to me that sk->sk_backlog_len does not
provide an accurate estimate of backlog length; this reduces the
usefulness of the "limit" argument to sk_add_backlog.
The problem is that, under heavy load, sk->sk_backlog_len can grow
arbitrarily large, even though the actual amoun
I am creating a kernel module that implements the Homa transport
protocol (see paper in SIGCOMM 2018) and as a Linux kernel newbie I'm
struggling a bit to figure out how all of Linux's network plumbing
works.
I'm currently having problems retransmitting an sk_buff after packet
loss and hoping that
11 matches
Mail list logo
