Simon Goldschmidt | 1 Nov 13:28 2007
Picon

[patch #6250] MSG_MORE flag for send


Follow-up Comment #19, patch #6250 (project lwip):

Looks fine!

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6250>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/
Kieran Mansley | 1 Nov 13:32 2007
Picon

[bug #21181] Initial congestion window


Follow-up Comment #5, bug #21181 (project lwip):

Let's stick with the 2MSS initial congestion window, but the other change
that this bug suggests looks like a good one to me.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21181>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Kieran Mansley | 1 Nov 13:34 2007
Picon

[bug #21307] tcp connect problem


Update of bug #21307 (project lwip):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21307>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 1 Nov 13:47 2007
Picon

[patch #6253] Added csum to struct pbuf.


Follow-up Comment #4, patch #6253 (project lwip):

> I'm pretty sure that some developers will ask you to enable
> that with an option

Of course!

> Do you have read "task #6849 : Test how checksum on copy could
> be integrated into the stack"

In fact I did some work on that task already and it also included adding
flags to the struct pbuf. Only in my case, this was needed because I was
adding one checksum per pbuf (when copying into the pbuf for sending). Of
course this must be an option and you trade speed for size!

Andrey's suggested patch is different, of course, since it would turn off
checksum generation for the TX side because those are automatically generated
by the HW, I suppose (my checksum-checking-HW discarded packets with wrong
checksums immediately, by the way, which seems to be even faster than Andrey's
patch).

> usually there are alignment constraints, particularly if
> caching is also involved, in which case you have to keep packet
> data and other data (including struct pbuf itself) in different
> cache lines

That's true of course, but it's not covered today! We would need a second
memory alignment setting for DMA data. Then, when adding fields to the struct
pbuf, the struct would automatically be aligned for DMA needs.
(Continue reading)

Andrey Volkov | 1 Nov 13:48 2007

Re: [patch #6253] Added csum to struct pbuf.

Frédéric Bernon wrote:
> Follow-up Comment #2, patch #6253 (project lwip):
> 
>> Is HWD_SUPPORT_CSUM will be appropriate?
>> 
>> Andrey
> 
> CHECKSUM_HARDWARE_SUPPORT (to be in the same spirit than other
> CHECKSUM_xxx) ?
> 
Ok, accepted.

> Do you have read "task #6849 : Test how checksum on copy could be
> integrated into the stack" (https://savannah.nongnu.org/task/?6849) ?
> 
> 
Yes, but I introduce this field mainly for next purposes:
 1) speed up reassembly of incoming ip packets. In reassembly case,
    ip payload csum of each fragment should be stored somewhere.
    (IMHO, pbuf is very appropriate for it).
 2) Hardware usually could calculate ip payload/headers checksum,
    but not tcp/udp pseudo checksum, hence ip csum should be stored.
    Also, I dislike to mix different levels of stack in one piece
    of code. I.e. if I've ip checksum in eth driver, I could undef
    CHECKSUM_CHECK_IP, but not CHECKSUM_CHECK_TCP/CHECKSUM_CHECK_UDP,
    since I don't know it in driver level.
And,
 3) In my hwd. driver, I don't 'memcpy' incoming packets, DMA do it
    directly to pbuf.

(Continue reading)

Kieran Mansley | 1 Nov 13:49 2007
Picon

[bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe


Follow-up Comment #11, bug #21433 (project lwip):

I have to admit I'm a bit uneasy about increasing the amount of stuff that we
support from interrupt context because in many cases doing this sort of thing
from interrupt context is a bad idea.  There are cases (perhaps like the one
that prompted this) where it helps, but by adding support we make it tempting
for people to write bad code.

I pretty much agree with Simon in comment#5.  i.e. all of the suggestions
have their merits but none is ideal.  If Jonathan can persuade Simon that
SYS_ARCH_PROTECT is OK then that would be a relatively simple change I think. 

Simon - can you clarify your objection?  I like the list-postponement as that
avoids doing it at interrupt time, but the extra code and overhead to support
this might be too much for a rarely necessary feature. With it not working for
all APIs and NO_SYS we'd need something else as well.

Either way, I think this is best left till after 1.3.0 otherwise we'll never
get it out.  

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21433>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
(Continue reading)

Kieran Mansley | 1 Nov 13:55 2007
Picon

[patch #6250] MSG_MORE flag for send


Follow-up Comment #20, patch #6250 (project lwip):

Apologies for not entering the debate earlier, but I think you've all come to
the right decisions without me, so please close as fixed once the patch goes
in.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6250>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Kieran Mansley | 1 Nov 13:57 2007
Picon

[task #7421] Implement SO_RCVBUF


Follow-up Comment #1, task #7421 (project lwip):

Seems like a good idea and fits well with lwIP's lightweight nature.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7421>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Kieran Mansley | 1 Nov 14:01 2007
Picon

[patch #6253] Added csum to struct pbuf.


Follow-up Comment #5, patch #6253 (project lwip):

> include the checksum in the pbuf contents somewhere, either 
> the start or end.

Good idea.  

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6253>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
Simon Goldschmidt | 1 Nov 14:01 2007
Picon

[bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe


Follow-up Comment #12, bug #21433 (project lwip):

> plug_holes isn't a problem

Of course it's not, since there is no loop in it!

[Kieran wrote:]
> I have to admit I'm a bit uneasy about increasing the amount of > stuff
that we support from interrupt [->bad code]

[Jonathan wrote:]
> I would have guessed (possibly wrongly) that most ethernet
> driver systems do operate at thread level because the amount
> of processing

For RX, I agree; for TX enqueuing also. But freeing ref'ed pbufs when they
are actually sent can be done quite fast in interrupt context, I think
(nothing to be copied), and I don't see bad coding here.

> [if] SYS_ARCH_PROTECT is OK then that would be a relatively 
> simple change I think.

If it's configurable it would be OK with me but in general it leads to very
long periods of time where the interrupts are disabled (which _is_ bad code to
me; after all it's nearly the same as a very long running ISR). But since this
seems the only nice solution for both NO_SYS settings, I'm OK with it as long
as

a) using semaphore is the default
(Continue reading)


Gmane