netdev - Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=53F3O511Uq83dP75brGkJMgN_-OR9W0VJS1p-@mail.gmail.com>
Date:	Mon, 20 Sep 2010 10:50:22 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Changli Gao <xiaosuo@...il.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, sridharr@...gle.com
Subject: Re: [PATCH] xmit_compl_seq: information to reclaim vmsplice buffers

>
> > Using recvmsg data in this manner is sort of a cheap way to get a
> > "callback" for when a vmspliced buffer is consumed.  It will work
> > well for a client where the response causes recvmsg to return.
>
> In this case, we don't need it. The response is sufficient to indicate
> the request is sent out, and the corresponding pages are available for
> the other use.

The response might seem sufficient, but there is no guarantee this
works generally for every application protocol.  The specific
requirement for TCP is that the page cannot be reused before its data
has been acked; if this does not hold then data corruption becomes an
issue.  Given that danger, I would rather the mechanism be unambiguous
about when the data has been consumed, rather than each application
protocol trying to figure this out using its heuristics.

>
> > On the server side it works well if there are a sufficient
> > number of requests coming on the connection (resorting to the
> > timeout if necessary as described above).
>
> If no response is sent out by the client, the timeout mechanism may
> slow down the data transfer.
>
Why would that slow down a transfer?

>
> I think we should not mix RX and TX. Maybe we can add a new epoll
> event to indicate that the snd bufer is advanced.
>
This is possible, but seems more heavyweight that needed.  I don't see
that it's going to be critical to reclaim buffers as soon as they have
been completed, some laziness in do this seems like a reasonable
tradeoff and we should still have a reasonable working set.

Tom

> --
> Regards,
> Changli Gao(xiaosuo@...il.com)
--
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