Re: [tipc-discussion] Solution to problem of losing fragmentedmessages

[Stephens, A. <all...@wi...>]

Randy wrote:

> > I agree with Jon's goals of zero copy and only copying when 
> the user 
> > does a read as I'm sure you do Allan.

Absolutely.

> > Consider two other use cases:
> > 
> > 1. Jumbo frame network with MTU of say 9600 bytes.
> > Many (well behaving) NICs will present MTU sized packet to 
> TIPC as a 
> > non-linear skb.
> > Currently TIPC linearizes these and that's fine until there's a 
> > shortage of memory.
> > 
> > I submitted a patch some time ago to deal with the payload packets 
> > without linearizing them. Is it worth re-basing and 
> re-submitting this work?

If you've got something that can eliminate unnecessary linearization, it
sounds like it would be worthwhile to rebase this against TIPC 2.0 and
resubmit it. The trick is to ensure that any such work handles *all* of
the paths in TIPC that need to process incoming messages, and not just
the basic one in which a data message is passed to a socket receive
queue; for example, the code needs to handle bundled messages, message
fragments, name table messages, and so on.

Another question to ask how such a change impacts TIPC's native API.
Right now, code using the native API is guaranteed that any callback
routine that is given a message can access the contents of the message
as a linear array. Is this something that we need to continue
supporting?

Regards,
Al