[lwip-users] Re: [lwip] Anyone Using An Architecture That Isn't little or big endian?

[John C. Toman]

Yes, byte swapping could be entirely the responsibility of the packet or 
device driver, but I don't think it makes sense to place that burden there.

Right now in lwIP the packets are assumed to be in network (big endian) 
byte order when they reach the network interface / packet driver (or 
when incoming packets leave the network interface to be processed by 
lwIP). This I think is fine. lwIP does byte reordering in the correct 
places. lwIP doesn't unnecessarily burden packet driver developers with 
worrying about byte order; it takes care of swapping itself. This 
increases the code complexity of lwIP, but decreases the complexity of 
the device driver. This is good because there's one lwIP code base and 
many different device drivers. It makes sense to design any complexity 
like that into lwIP itself and make the device drivers simpler to write.

Regards,

John

Earle Clubb wrote:

>Maybe I'm missing something, but it seems to me that all of the little/big
>endian conversions in the stack can be eliminated if the required byte
>swapping is done in the device driver just before the bytes are sent to the
>network device.  Does this make sense, or am I way off?
>
>
>Earle Clubb
>
>Software Engineer
>Valcom, Inc.
>
>E-mail: address@hidden
>Voice: (540) 563-2000 ext.253
>
>-----Original Message-----
>From: address@hidden [mailto:address@hidden Behalf Of John C.
>Toman
>Sent: Monday, August 19, 2002 3:04 PM
>To: address@hidden
>Subject: [lwip] Anyone Using An Architecture That Isn't little or big
>endian?
>
>
>Just checking. I'm considering writing and submitting code which would
>eliminate many unnecessary byte swaps for little endian architectures,
>specifically for code constants, without affecting big endian
>architectures. I'm planning on making changes at least for my system and
>will contribute them back to the lwIP tree if others are interested. For
>instance, consider:
>
>Currently in lwIP (one example from etharp.h):
>
>#define ETHTYPE_ARP 0x0806
>#define ETHTYPE_IP  0x0800
>
>When these are used, they must be byte-swapped in the little endian case
>(from ethernetif.c):
>
>    switch(htons(ethhdr->type)) {
>    case ETHTYPE_IP:
>      arp_ip_input(netif, p);
>      pbuf_header(p, -14);
>      netif->input(p, netif);
>      break;
>    case ETHTYPE_ARP:
>      p = arp_arp_input(netif, ethernetif->ethaddr, p);
>      if(p != NULL) {
>        low_level_output(ethernetif, p);
>        pbuf_free(p);
>      }
>      break;
>
>With a #ifdef for LITTLE_ENDIAN systems in the header files, this
>example would become:
>
>etharp.h:
>
>#ifdef LITTLE_ENDIAN
>#  define ETHTYPE_ARP 0x0608
>#  define ETHTYPE_IP  0x0008
>#else
>#  define ETHTYPE_ARP 0x0806
>#  define ETHTYPE_IP  0x0800
>#endif
>
>Then the code piece in ethernetif.c loses the htons() call, saving code
>and execution time in the little endian case without harming the big
>endian case:
>
>    switch(ethhdr->type) {
>    case ETHTYPE_IP:
>      arp_ip_input(netif, p);
>      pbuf_header(p, -14);
>      netif->input(p, netif);
>      break;
>    case ETHTYPE_ARP:
>      p = arp_arp_input(netif, ethernetif->ethaddr, p);
>      if(p != NULL) {
>        low_level_output(ethernetif, p);
>        pbuf_free(p);
>      }
>      break;
>
>My thinking was that dozens of htons, htonl, ntohs and ntohl calls in
>lwIP could be eliminated this way or in similar ways, resulting in
>cleaner code, as well as smaller code size and increased performance for
>little endian systems.
>
>The one drawback I can see to this approach is if there are other
>architectures that store bytes differently than little or big endian,
>they would need to come up with their own constants that represent the
>network-storage format on their systems ...
>
>Regards,
>
>John
>
>
>[This message was sent through the lwip discussion list.]
>
>[This message was sent through the lwip discussion list.]
>  
>




[This message was sent through the lwip discussion list.]