Rev 40: Raw impl. of ibwrapper test tool. in http://samba.org/~tridge/psomogyi/

tridge at samba.org tridge at samba.org
Tue Dec 19 01:14:05 GMT 2006


Peter,

 > Sorry, I don't have such an event possibility in verbs.

You sure there is no way to get an underflow event? Network cards
usually have an interrupt for underflow, and it would seem pretty
silly to have no way to expose that in verbs, its quite basic to flow
control.

If you really can't get it from verbs then you could use a timer
(using event_add_timed()). Setup a timer when you need to queue a
packet and the outgoing queue is full. Set the timer for maybe 1
second and log a message the first time it happens. We don't want a
fast timer as we really want to notice if this happens, as it means we
have something wrong elsewhere.

 > Receiver side is more interesting: your implementation also incomplete 
 > (ctdb_tcp_incoming_read: see "combined or partial packets").

yep, I completed that today. It now handles both partial packets and
receiving more than one packet. It has a fast path for the usual case
of nicely aligned packets.

To make this work properly I added a new transport level method that
allows the transport to do the packet allocation. You might find that
useful for the ib transport as well.

 > BTW. Now I definitely see unavoidable a 4-byte message length prefix for this 
 > before each message. Strangely I don't see it in your transport 
 > implementation in spite of you are streaming. (Having it in hdr doesn't tell 
 > our transport how to feed upper layer - where to cut the message
 > end.)

The length value in the header is always the first 4 bytes of every
message. The tcp transport now relies on that. You should be able to
use that in ib too.

 > I'm going to implement a solution for this one, too - in ib case only for 
 > receiving splitted buffers (I can't [fore]tell in time how big buffer is 
 > needed in advance). So upper layer would receive message _in one_ block + 
 > _not more_.

ok, but please fast-path this for the common case that no
splitting/combining is needed. 

Cheers, Tridge


More information about the samba-technical mailing list