|
Piero,
I take it this is an FPGA you are working
with? I tried filtering the packets in the driver last year and found it
to be too slow to handle everything that may come in. I'm using a
Mircoblaze soft core in my Xilinx FPGA and it can't get out of it's own
way. There are some much faster FPGAs especially if you use the power
PC core but they get very expensive. We went down the route of having our
core customized so that our driver sees our TCP packets and our ARPs only.
On boot up, I pass the MAC address and our IP to the core and then turn on the
MAC and broadcast filters. For DHCP, I turn on the MAC filter, wait
until I get my IP address, send it to the core and then turn on the
broadcast filter. It works and my uP is free to do other
things.
Steve
----- Original Message -----
Sent: Friday, January 25, 2008 11:32
AM
Subject: Re: [lwip-devel] Re:
[lwip-users] filter broadcast packet
2008/1/25, Jonathan Larmour <address@hidden>:
Piero
74 wrote:
>
> My board will be a simple
device in a typical windows or unix
>
network, which will accept tcp connection
for options programming
> and upgrade, and send/receive udp
packets on event.
> For marketing reason it has to implement
DHCP.
> So my idea:
> 1. on bootstrap, using dhcp session for
get IP -----> driver will not
> block broadcast packet
> 2.
when a new IP is available, enable broadcast packet filtering, except
ARP
>
> What do you think?
You would have to make sure it
worked for DHCP renewals as well.
... i understood... i thought using DHCP client only on boot, and
after getting ip stop it... but it's NO correct... right?
>
But backing up a little, since the packets have to be processed by
the
> tcpip thread really, you may be able to
do that directly from your IRQ,
> rather than
from another separate thread. It depends on whether
your
> mailbox implementation is
interrupt-safe. If it is, then you could
>
post it
> to the mailbox
directly.
>
>
> mmmmm..... I want to understand
your suggest....
>
> Do you suggest to me to execute code of
ethernetif_input in irq
> function? i saw that this function answer to
arp packet and send packet
> pbuf to mailbox using
tcpip_input.
No!
This was a problem with code in 1.2.0 and
earlier. The ARP code is not safe
to call from any context other than the
tcpip thread. For current CVS (and
1.3.0) you need to be calling
tcpip_input, which will automatically deal
with the ARP processing for
you, but will do it all in the correct context
of the tcpip
thread.
What I'm suggesting is calling tcpip_input from your irq, but
only if your
mboxes are irq-safe.
ops... i'm working on lwip 120.... so, you suggest me to use lwip
130rc1.... which has different ethernetif_input (i'm seeing now...) and call
tcpip_input from my irq...
i'm thinking to se a flag when a emac irq occur,
and reset it on exit, and check this flag on sy_mbox_post... in this way i can
choose how rtos function call, normal or irq safe, depending on sys_mbox_post
is called from irq or from stack. What do you think?
bye again,
Piero
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.
------["Si fractum non sit, noli id
reficere"]------
Opinions==mine
_______________________________________________
lwip-users
mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing
list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
|