[bug #26132] Packet processing optimization using static message

[Mario Castelán Castro-2]

URL:
  <http://savannah.nongnu.org/bugs/?26132>

                 Summary: Packet processing optimization using static message

                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: blackfin
            Submitted on: Thu 09 Apr 2009 01:59:17 PM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release:
            lwIP version: 1.3.0

    _______________________________________________________

Details:

Packet processing optimization using static message (one for rx and one for
tx) from low level interrupt routine to the upper level lwip layers. As these
messages are marked with static flag they will never get destroyed (associated
semaphore will never get destroyed).

Description:
 An additional field flag has been added in the tcpip_msg structure. If the
flag is marked as TCPIP_MSG_FLAG_STATIC then the message will not be freed.
During lwIP initialization two static messages were created one for Rx and one
for Tx. Both of these messages have the following values set

 Message type: TCPIP_MSG_CALLBACK
 Message flag: TCPIP_MSG_FLAG_STATIC
 Handler(s): process_rcvd_packets  (for rx message)
                      process_xmtd_packets (for tx message)

In case of reception the low level ISR queues up the packets and posts the rx
message. tcpip_thread upon receiving the message processes the packets by
invoking rx_processing_handler.  If the queue is not empty then low level
layer will not post the message again but simply appends to the list.
Appropriate protection is adopted whilst manipulating the queue.

Similarly in case of transmit complete the buffer is returned back to the
lwip layer and tx_processing_handler is called to return back the buffer.

Some operating systems has special API to post semaphores from ISR domain so
we added sys_mbox_ISR_post() API to distinguish between ISR post’s to thread
level post’s.

Files changed:
lwipincludetcpip.h  line 104
lwipapitcpip.c  line 233,428

Changes:
lwipincludetcpip.h line 110
From:
struct tcpip_msg {
  enum tcpip_msg_type type;
  sys_sem_t *sem;
  union {
…};

To:

enum tcpip_msg_flags {
    TCPIP_MSG_FLAG_STATIC = 1   // msg area is in static storage, not memp
};
struct tcpip_msg {
  enum tcpip_msg_type type;
  u32_t flags;
  union {
…};

tcpip.c
line 233:
From:
tcpip_thread(void *arg):
    default:
      break;
    }
    memp_free(MEMP_TCPIP_MSG, msg);

To:
tcpip_thread(void *arg):
    default:
      break;
    }

    if ((msg->flags & TCPIP_MSG_FLAG_STATIC) == 0)
        memp_free(MEMP_TCPIP_MSG, msg);


From:

tcpip_input(struct pbuf *p, struct netif *inp) line 331:
  msg->type = TCPIP_MSG_INPUT;
  msg->msg.inp.p = p;
To:
tcpip_input(struct pbuf *p, struct netif *inp) line 331:
  msg->type = TCPIP_MSG_INPUT;
  msg->flags = 0;
  msg->msg.inp.p = p;

From:
tcpip_callback(void (*f)(void *ctx), void *ctx) line 368:
  msg->type = TCPIP_MSG_CALLBACK;
  msg->msg.cb.f = f;

To:
tcpip_callback(void (*f)(void *ctx), void *ctx) line 368:
  msg->type = TCPIP_MSG_CALLBACK;
  msg->flags = 0;
  msg->msg.cb.f = f;


From:

tcpip_apimsg(struct api_msg *apimsg) line 428:
  msg->msg.apimsg = apimsg;
  sys_mbox_post(mbox, msg);
}

To:
tcpip_apimsg(struct api_msg *apimsg) line 428:
  msg->flags = 0;
  msg->msg.apimsg = apimsg;
  sys_mbox_post(mbox, msg);
}






    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro-2]

Follow-up Comment #1, bug #26132 (project lwip):

A few questions:

Can you give any information about what sort of performance improvement this
optimization might give?

I notice that your changes remove the "sys_sem_t *sem;" from struct
tcpip_msg.  Is this really unused?

How does the user of the static message know that it is OK for it to re-use
the static message?  Is it implicit that only one of these messages can
exist.

Finally, which source version are your changes made against?  They don't seem
to correspond to CVS head.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro-2]

Update of bug #26132 (project lwip):

                  Status:                    None => Need Info              


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro-2]

Follow-up Comment #2, bug #26132 (project lwip):

> Some operating systems has special API to post semaphores from
> ISR domain so we added sys_mbox_ISR_post() API to distinguish
> between ISR post’s to thread level post’s.

That's what we use sys_mbox_trypost() for.

The general idea of one static message isn't too bad, but to include this
"patch" into lwIP, it would be necessary to include the input packet list
handling, too.

As such, I'm not convinced this should go in to the lwIP code...

I also don't think memp_malloc()/memp_free() is a bottleneck here (you could
implement the list/not calling sys_mbox_post a second time without the static
message, too).

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel