Hi Vitali.

On Wed, Nov 12, 2008 at 09:07:43AM -0800, Lovich, Vitali (vlovich@qualcomm.com) wrote:
quoted text
> I think you misunderstand how the API works.  Yes the user could call send from the thread he's filling in data from.  But the idea is that he would ideally do this from another thread so that it's possible to control latency between packet sends.  Additionally, even without trying to control latency, there would still have to be complicated logic in userspace to determine when enough packets have been placed in the buffer to overcome the cost of a system call.
> 
> This is why we need to know which frame in the ring buffer the skb is associated with.

What's the problem of invoking send machinery from different thread?
You can wait in appropriate syscall until multiple packets have been
sent and then return, or update some shared flag in the mapped area
which says that something is being sent. When dev_queue_xmit() for
selected set of packets completes, you can update that variable, and
based on its value userspace can overwrite the area used by already
sent packets.

I see the only reason to have a notification about skb completion is an
absolute need to send sync data, i.e. packet data can not be overwritten
until packet reaches the media. But getting that existing Linux
splice/sendfile and any other ->sendpage() users are racy in this regard
for centuries, this does not look as a strong demand for me.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html