[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] "the ARP layer is not protected against concurrent acce
From: |
Kieran Mansley |
Subject: |
Re: [lwip-users] "the ARP layer is not protected against concurrent access" |
Date: |
Mon, 05 Mar 2007 09:09:12 +0000 |
On Fri, 2007-03-02 at 22:57 +0100, Goldschmidt Simon wrote:
> Hi list,
>
> CHANGELOG says:
> FUTURE
> ...
> * TODO: the ARP layer is not protected against concurrent access. If
> you run from a multitasking OS, serialize access to ARP (called
> from
> your network device driver and from a timeout thread.)
>
> My idea was to do all ARP processing in context of the tcpip_thread
> (like Frédéric suggested). In fact, I have already done so in my local
> sources (and of course, it works for a while now :)
>
> I've done this by adding 2 new functions (and some new messages) to
> tcpip.h/.c:
>
> err_t tcpip_input_w_arp(struct pbuf *p, struct netif *inp);
> for incoming IP packets, ETH header not removed to update ARP entry
> err_t tcpip_arp_input(struct pbuf *p, struct netif *inp);
> for incoming ARP packets
>
> (tcpip_input() would not be needed any more, but you have the choice
> when writing the ethernetif.c)
>
> All access to etharp.c is thus done in the context of the
> tcpip_thread, which saves us the concurrent access protection.
> Downside is that ARP requests take a little longer to process (context
> switch) but I think that's a minor one.
Sounds like a reasonable suggestion to me. I'm slightly concerned by
you saying that the tcpip_input() function wouldn't be needed anymore.
Can you explain why?
> AS far as I know (but I'm not using it by now), that wouldn't affect
> raw API programs running without an OS, since they don't use messages,
> anyway. This would simply be a matter of assigning another input
> function for netifs (and maybe another input function, e.g. netif-
> >arp_input()).
Any raw API users/experts care to comment on this aspect? Would be nice
if we could come up with a simple solution that addressed this problem
for all APIs.
Kieran