MSG_MORE flag for send

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

MSG_MORE flag for send

Marc CHALAND-2
Hi,

We started a port of lwip on TUDOS (L4) infrastructure. We based this
port on the last stable version of lwip : 1.2.0. We encountered some
difficulties but we hope this port will be released soon.

We use TUDOS BID. It uses uclibc library. It implements a socket.h
file which has some incompatibilities with lwip one. I did some dirty
things to avoid this (I split sockets.h into 3 files). Maybe have you
some tips to cope this style of problem ?

For this port, I need a functionnality which seems to me interesting
for 1.3.0 version. This little patch has been done and tested on
1.2.0. I did a port to current CVS version. This functionnality allows
to late the TCP PUSH flag.

Regards
Marc

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

lwip-071026.patch (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

goldsimon@gmx.de
Interesting patch (this functionality is required by the TCP RFCs by  
the way), but I'd rather solve this without adding an extra parameter  
to a load of functions throughout the whole stack (I can already hear  
people saying' why add an extra parameter (which might be put on the  
stack when calling the funciton) for something I don't need?').

Anyway, as this is something to be discussed and in order it isn't  
just forgot, you should send in a patch on savannah.

Simon

Am 26.10.2007 um 21:41 schrieb Marc CHALAND:

> Hi,
>
> We started a port of lwip on TUDOS (L4) infrastructure. We based this
> port on the last stable version of lwip : 1.2.0. We encountered some
> difficulties but we hope this port will be released soon.
>
> We use TUDOS BID. It uses uclibc library. It implements a socket.h
> file which has some incompatibilities with lwip one. I did some dirty
> things to avoid this (I split sockets.h into 3 files). Maybe have you
> some tips to cope this style of problem ?
>
> For this port, I need a functionnality which seems to me interesting
> for 1.3.0 version. This little patch has been done and tested on
> 1.2.0. I did a port to current CVS version. This functionnality allows
> to late the TCP PUSH flag.
>
> Regards
> Marc
> <lwip-071026.patch>
> _______________________________________________
> lwip-devel mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-devel



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Jonathan Larmour
Simon Goldschmidt wrote:
> Interesting patch (this functionality is required by the TCP RFCs by  
> the way),

Are you sure about that? We already only set PSH on the last segment of
enqueued data from a single 'write', so isn't that all that is required?
It seems more to me that this is an extension to give the user more
control over when to send a PSH, rather than it being at the end of every
'write'.

> but I'd rather solve this without adding an extra parameter  
> to a load of functions throughout the whole stack (I can already hear  
> people saying' why add an extra parameter (which might be put on the  
> stack when calling the funciton) for something I don't need?').

I can see you glancing at me ;-). But yes, I think this patch would need
more discussion and development. I am a bit concerned with the
consequences of running out of memory (segs, pbufs, netbufs, ...) - much
more likely for us than other stacks of course. My concern, which may be
unjustified, is that PSH can affect the remote end's behaviour for ACKs.
And if so, could result in unnecessary delays before remote ACKs are
transmitted, leading to a stalled local unacked queue. I'd have to look
more closely at the RFCs and existing practice to find out for sure
admittedly.

Certainly, adding an extra param is not a requirement; this could be done
with a separate API message to set a flag in the pcb, e.g. in tcp.h:
#define TF_DELAY_PSH (u8_t)0x80U

And then in tcp_enqueue:
    if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
        0 == (pcb->flags & TF_DELAY_PSH) ) {
      TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
    }

New equivalent functions can be provided in the higher APIs. The advantage
there being that they are left out if unused (if using a linker with dead
function garbage collection).

Rather than there being a specific API message to set this flag (which
would take space that couldn't be removed without an lwipopts.h define),
it may be better to have one to get/set any PCB flag, which has more
generic purpose.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

goldsimon@gmx.de

Am 27.10.2007 um 16:45 schrieb Jonathan Larmour:

> Simon Goldschmidt wrote:
>> Interesting patch (this functionality is required by the TCP RFCs  
>> by  the way),
>
> Are you sure about that? We already only set PSH on the last  
> segment of enqueued data from a single 'write', so isn't that all  
> that is required? It seems more to me that this is an extension to  
> give the user more control over when to send a PSH, rather than it  
> being at the end of every 'write'.

Sorry, seems I remembered it wrong, it's a MAY in RFC 1122 (page  
107), not a MUST.

>
>> but I'd rather solve this without adding an extra parameter  to a  
>> load of functions throughout the whole stack (I can already hear  
>> people saying' why add an extra parameter (which might be put on  
>> the  stack when calling the funciton) for something I don't need?').
>
> I can see you glancing at me ;-). But yes, I think this patch would  
> need more discussion and development. I am a bit concerned with the  
> consequences of running out of memory (segs, pbufs, netbufs, ...) -  
> much more likely for us than other stacks of course. My concern,  
> which may be unjustified, is that PSH can affect the remote end's  
> behaviour for ACKs. And if so, could result in unnecessary delays  
> before remote ACKs are transmitted, leading to a stalled local  
> unacked queue. I'd have to look more closely at the RFCs and  
> existing practice to find out for sure admittedly.

Agree with you there.

>
> Certainly, adding an extra param is not a requirement; this could  
> be done with a separate API message to set a flag in the pcb, e.g.  
> in tcp.h:

But that would set the push flag for every segment. I'd rather let  
netconn_write put the flag into the message (flags are supported in  
socket API, why not in netconn API?). Then netconn layer can set the  
flag, call TCP and set it back again.

> #define TF_DELAY_PSH (u8_t)0x80U
>
> And then in tcp_enqueue:
>    if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
>        0 == (pcb->flags & TF_DELAY_PSH) ) {
>      TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
>    }
>
> New equivalent functions can be provided in the higher APIs. The  
> advantage there being that they are left out if unused (if using a  
> linker with dead function garbage collection).
>
> Rather than there being a specific API message to set this flag  
> (which would take space that couldn't be removed without an  
> lwipopts.h define), it may be better to have one to get/set any PCB  
> flag, which has more generic purpose.

That might be a good idea, much like get/setsockopt.

Simon




_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Jonathan Larmour
Simon Goldschmidt wrote:

>
> Am 27.10.2007 um 16:45 schrieb Jonathan Larmour:
>
>> Simon Goldschmidt wrote:
>>
>>> Interesting patch (this functionality is required by the TCP RFCs  
>>> by  the way),
>>
>>
>> Are you sure about that? We already only set PSH on the last  segment
>> of enqueued data from a single 'write', so isn't that all  that is
>> required? It seems more to me that this is an extension to  give the
>> user more control over when to send a PSH, rather than it  being at
>> the end of every 'write'.
>
> Sorry, seems I remembered it wrong, it's a MAY in RFC 1122 (page  107),
> not a MUST.

I think you meant page 82 (specifically 4.2.2.2) but yeah I see it there
as MAY.

>> Certainly, adding an extra param is not a requirement; this could  be
>> done with a separate API message to set a flag in the pcb, e.g.  in
>> tcp.h:
>
>
> But that would set the push flag for every segment.

To be clear, I meant the new TF_DELAY_PSH I proposed in the PCB flags, not
the PSH flag in a segment. (Too many "flags" around I think :-)). Without
TF_DELAY_PSH set, the current behaviour would be preserved.

> I'd rather let  
> netconn_write put the flag into the message (flags are supported in  
> socket API, why not in netconn API?). Then netconn layer can set the  
> flag, call TCP and set it back again.

That would work too.

>> #define TF_DELAY_PSH (u8_t)0x80U
>>
>> And then in tcp_enqueue:
>>    if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
>>        0 == (pcb->flags & TF_DELAY_PSH) ) {
>>      TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
>>    }
>>
>> New equivalent functions can be provided in the higher APIs. The  
>> advantage there being that they are left out if unused (if using a  
>> linker with dead function garbage collection).
>>
>> Rather than there being a specific API message to set this flag  
>> (which would take space that couldn't be removed without an  
>> lwipopts.h define), it may be better to have one to get/set any PCB  
>> flag, which has more generic purpose.
>
>
> That might be a good idea, much like get/setsockopt.

Yep, like them, with room for expansion in the future. Probably best not
to restrict to PCB flags even.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Frédéric BERNON-2
>>>> Interesting patch (this functionality is required by the TCP RFCs  by
>>>> the way),
>>>
>>>
>>> Are you sure about that? We already only set PSH on the last  segment of
>>> enqueued data from a single 'write', so isn't that all  that is
>>> required? It seems more to me that this is an extension to  give the
>>> user more control over when to send a PSH, rather than it  being at the
>>> end of every 'write'.
>>
>> Sorry, seems I remembered it wrong, it's a MAY in RFC 1122 (page  107),
>> not a MUST.
>
> I think you meant page 82 (specifically 4.2.2.2) but yeah I see it there
> as MAY.

What RFC reference do you use? rfc.net site is pretty good, since you can
give links like http://rfc.net/rfc1122.html#p82 , and even like
http://rfc.net/rfc1122.html#s4.2.2.2, but this last don't work : (

>
>>> Certainly, adding an extra param is not a requirement; this could  be
>>> done with a separate API message to set a flag in the pcb, e.g.  in
>>> tcp.h:
>>
>>
>> But that would set the push flag for every segment.
>
> To be clear, I meant the new TF_DELAY_PSH I proposed in the PCB flags, not
> the PSH flag in a segment. (Too many "flags" around I think :-)). Without
> TF_DELAY_PSH set, the current behaviour would be preserved.
>
>> I'd rather let  netconn_write put the flag into the message (flags are
>> supported in  socket API, why not in netconn API?). Then netconn layer
>> can set the  flag, call TCP and set it back again.
>
> That would work too.
>
>>> #define TF_DELAY_PSH (u8_t)0x80U
>>>
>>> And then in tcp_enqueue:
>>>    if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
>>>        0 == (pcb->flags & TF_DELAY_PSH) ) {
>>>      TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
>>>    }
>>>
>>> New equivalent functions can be provided in the higher APIs. The
>>> advantage there being that they are left out if unused (if using a
>>> linker with dead function garbage collection).
>>>

Without adding a new parameter, since the existing "copy" parameter seems to
be forwarded from sockets.c to tcp_out.c (in tcp_enqueue), why don't use it?
We can rename it apiflags - or something else - (since flags is usein
tcp_enqueue like "tcp flags"). I don't have study all case, but msg_more is
an option "per 'write' call", like the "copy" option.

>>> Rather than there being a specific API message to set this flag  (which
>>> would take space that couldn't be removed without an  lwipopts.h
>>> define), it may be better to have one to get/set any PCB  flag, which
>>> has more generic purpose.
>>
>>
>> That might be a good idea, much like get/setsockopt.
>
> Yep, like them, with room for expansion in the future. Probably best not
> to restrict to PCB flags even.
>
> Jifl
> --
> eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
> Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
> Registered in England and Wales: Reg No 4422071.
> ------["The best things in life aren't things."]------      Opinions==mine
>
>
> _______________________________________________
> lwip-devel mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>




_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Marc CHALAND
In reply to this post by goldsimon@gmx.de
2007/10/27, Simon Goldschmidt <[hidden email]>:
>
> Interesting patch (this functionality is required by the TCP RFCs by
> the way),

lwip already implement set of PSH flag at the end of write. Just to
present the context of lwip port on L4. We decided to put IP stack in
a separate task to prevent memory overflows for example and such
things. So client task communicate to this task by using a flexpage
(4096 bytes). As a consequence, client task has to cut what has to be
written into chunks.

For example, if a client task needs to write 5000 bytes, 4096 bytes
will be sent to stack, and then 904 bytes. Without the patch, two PSH
flags will be set instead of only one if lwip and application are in
the same task.

> but I'd rather solve this without adding an extra parameter
> to a load of functions throughout the whole stack (I can already hear
> people saying' why add an extra parameter (which might be put on the
> stack when calling the funciton) for something I don't need?').

I didn't think about using pcb. However, how stack will know that last
data written is last data ?

> Anyway, as this is something to be discussed and in order it isn't
> just forgot, you should send in a patch on savannah.

OK, let's have a discussion :). I post the patch to savannah.

Marc


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Marc CHALAND
In reply to this post by Frédéric BERNON-2
2007/10/28, Frédéric BERNON <[hidden email]>:

> Without adding a new parameter, since the existing "copy" parameter seems to
> be forwarded from sockets.c to tcp_out.c (in tcp_enqueue), why don't use it?
> We can rename it apiflags - or something else - (since flags is usein
> tcp_enqueue like "tcp flags"). I don't have study all case, but msg_more is
> an option "per 'write' call", like the "copy" option.

This was my first idea. I didn't want to disturb eventual special use
of this byte ?
However, this require change of tcp_write and so on functions...

Marc


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Marc CHALAND-2
In reply to this post by goldsimon@gmx.de
2007/10/27, Simon Goldschmidt <[hidden email]>:
>
> Interesting patch (this functionality is required by the TCP RFCs by
> the way),

lwip already implement set of PSH flag at the end of write. Just to
present the context of lwip port on L4. We decided to put IP stack in
a separate task to prevent memory overflows for example and such
things. So client task communicate to this task by using a flexpage
(4096 bytes). As a consequence, client task has to cut what has to be
written into chunks.

For example, if a client task needs to write 5000 bytes, 4096 bytes
will be sent to stack, and then 904 bytes. Without the patch, two PSH
flags will be set instead of only one if lwip and application are in
the same task.

> but I'd rather solve this without adding an extra parameter
> to a load of functions throughout the whole stack (I can already hear
> people saying' why add an extra parameter (which might be put on the
> stack when calling the funciton) for something I don't need?').

I didn't think about using pcb. However, how stack will know that last
data written is last data ?

> Anyway, as this is something to be discussed and in order it isn't
> just forgot, you should send in a patch on savannah.

OK, let's have a discussion :). I post the patch to savannah.

Marc


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: MSG_MORE flag for send

Marc CHALAND-2
In reply to this post by Frédéric BERNON-2
> Without adding a new parameter, since the existing "copy" parameter seems to
> be forwarded from sockets.c to tcp_out.c (in tcp_enqueue), why don't use it?
> We can rename it apiflags - or something else - (since flags is usein
> tcp_enqueue like "tcp flags"). I don't have study all case, but msg_more is
> an option "per 'write' call", like the "copy" option.

This was my first idea. I didn't want to disturb eventual special use
of this byte ?
However, this require change of tcp_write and so on functions...

Marc


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RFC references (was Re: MSG_MORE flag for send)

Jonathan Larmour
In reply to this post by Frédéric BERNON-2
Frédéric BERNON wrote:
>>
>> I think you meant page 82 (specifically 4.2.2.2) but yeah I see it
>> there as MAY.
>
> What RFC reference do you use? rfc.net site is pretty good, since you
> can give links like http://rfc.net/rfc1122.html#p82 , and even like
> http://rfc.net/rfc1122.html#s4.2.2.2, but this last don't work : (

Most times nothing special - I usually just type it into my firefox address
bar, which googles it and tends to take me to faqs.org. I see rfc.net have
muddled their HTML, hence the link issue.

For giving out specific links, in the past I've used
http://www.freesoft.org/CIE/RFC/index.htm although that doesn't have
everything on one page. I now see there's one at CMU, e.g.
http://asg.web.cmu.edu/rfc/rfc1122.html which I guess may be the best of
all worlds.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel