[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] Recent change in pbuf.c
From: |
David Haas |
Subject: |
[lwip-users] Re: [lwip] Recent change in pbuf.c |
Date: |
Thu, 09 Jan 2003 01:19:51 -0000 |
This is a multi-part message in MIME format.
------=_NextPart_000_00D2_01C29BAA.260B1000
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
RE: [lwip] Recent change in pbuf.cHi Leon,
In my particular case, I am giving these buffers to the ethernet chip on =
receive. Unlike any of your other ports I looked at, my driver uses DMA =
to fill the pbufs directly and the payload pointer points to the first =
byte of the ethernet header. I am not supporting any PPP interfaces, so =
if an the payload pointer is offset, then that part of the buffer will =
never be used. Of course my problem is solved by using RAW buffers which =
don't have any offset, or as Magnus suggested, by changing the PBUF_LINK =
offset for my system.
I still have to question the need for the offset at the link layer. In =
fact the only thing I can think of is if you are running a remote-access =
server where the ethernet header is removed and a PPP header is =
inserted. I would claim that this is a somewhat specialized use and lwip =
should not be optimized for this. (or at least it should be documented).
Thanks,
David.
-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Tue 12/3/2002 3:22 AM
To: address@hidden
Cc:
Subject: Re: [lwip] Recent change in pbuf.c
=20
=20
Hello David,
=20
could you please indicate what part of the link header is =
prepended by your
Ethernet chip automatically?
=20
Jani's patch looks OK to me.
=20
Leon Woestenberg.
=20
=20
There was a recent change in pbuf.c by jani which says: "fix =
pbuf_alloc for
layer PBUF_LINK". This change has caused some problems for me =
and I want to
explore why.
=20
In my ethernet driver I am using PBUF_LINK when allocating pbufs =
for the
receive buffers. This recent change will reserve bytes in the =
front of the
pbuf, presumably for a link-level header. However, the ethernet =
chip will
be putting a link-level header in the packet already. So I would =
claim that
the offset for PBUF-LINK should be 0 (which it was before it was =
changed).
Now, I could change my allocation to PBUF_RAW, but I would claim =
that would
wrong.
=20
=20
[This message was sent through the lwip discussion list.]
=20
------=_NextPart_000_00D2_01C29BAA.260B1000
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [lwip] Recent change in pbuf.c</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi Leon,<BR><BR>In my particular case, I am giving =
these=20
buffers to the ethernet chip on receive. Unlike any of your other ports =
I looked=20
at, my driver uses DMA to fill the pbufs directly and the payload =
pointer points=20
to the first byte of the ethernet header. I am not supporting any PPP=20
interfaces, so if an the payload pointer is offset, then that part of =
the buffer=20
will never be used. Of course my problem is solved by using RAW buffers =
which=20
don't have any offset, or as Magnus suggested, by changing the PBUF_LINK =
offset=20
for my system.<BR><BR>I still have to question the need for the offset =
at the=20
link layer. In fact the only thing I can think of is if you are running =
a=20
remote-access server where the ethernet header is removed and a PPP =
header is=20
inserted. I would claim that this is a somewhat specialized use and lwip =
should=20
not be optimized for this. (or at least it should be=20
documented).<BR><BR>Thanks,<BR>David.<BR><BR><BR><BR><BR> &nbs=
p; =20
-----Original Message-----<BR> =
From:=20
address@hidden [<A=20
href=3D"mailto:address@hidden">mailto:address@hidden<=
/A>]<BR> =20
Sent: Tue 12/3/2002 3:22 =
AM<BR> To:=20
address@hidden<BR> =20
Cc:<BR> Subject: Re: [lwip] =
Recent=20
change in=20
pbuf.c<BR> <BR>  =
; <BR><BR><BR><BR> &n=
bsp; =20
Hello=20
David,<BR> <BR>  =
; =20
could you please indicate what part of the link header is prepended by=20
your<BR> Ethernet chip=20
automatically?<BR> <BR> &nb=
sp; =20
Jani's patch looks OK to=20
me.<BR> <BR> &n=
bsp; =20
Leon=20
Woestenberg.<BR> <BR>  =
; <BR> &n=
bsp;=20
There was a recent change in pbuf.c by jani which says: "fix pbuf_alloc=20
for<BR> layer PBUF_LINK". This =
change=20
has caused some problems for me and I want=20
to<BR> explore=20
why.<BR> <BR> &=
nbsp; =20
In my ethernet driver I am using PBUF_LINK when allocating pbufs for=20
the<BR> receive buffers. This =
recent=20
change will reserve bytes in the front of=20
the<BR> pbuf, presumably for a =
link-level header. However, the ethernet chip=20
will<BR> be putting a =
link-level=20
header in the packet already. So I would claim=20
that<BR> the offset for =
PBUF-LINK=20
should be 0 (which it was before it was=20
changed).<BR> Now, I could =
change my=20
allocation to PBUF_RAW, but I would claim that=20
would<BR> =20
wrong.<BR> <BR>  =
; <BR> =20
[This message was sent through the lwip discussion=20
list.]<BR> <BR><BR><BR></FONT></=
DIV></BODY></HTML>
------=_NextPart_000_00D2_01C29BAA.260B1000--
[This message was sent through the lwip discussion list.]