lwip-users
[Top][All Lists]
Advanced

[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>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
-----Original Message-----<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
From:=20
address@hidden [<A=20
href=3D"mailto:address@hidden";>mailto:address@hidden<=
/A>]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Sent: Tue 12/3/2002 3:22 =
AM<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:=20
address@hidden<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Cc:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: Re: [lwip] =
Recent=20
change in=20
pbuf.c<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;<BR><BR><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
Hello=20
David,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
could you please indicate what part of the link header is prepended by=20
your<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ethernet chip=20
automatically?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Jani's patch looks OK to=20
me.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
Leon=20
Woestenberg.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
There was a recent change in pbuf.c by jani which says: "fix pbuf_alloc=20
for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; layer PBUF_LINK". This =
change=20
has caused some problems for me and I want=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; explore=20
why.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
In my ethernet driver I am using PBUF_LINK when allocating pbufs for=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; receive buffers. This =
recent=20
change will reserve bytes in the front of=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pbuf, presumably for a =

link-level header. However, the ethernet chip=20
will<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be putting a =
link-level=20
header in the packet already. So I would claim=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the offset for =
PBUF-LINK=20
should be 0 (which it was before it was=20
changed).<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Now, I could =
change my=20
allocation to PBUF_RAW, but I would claim that=20
would<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
wrong.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[This message was sent through the lwip discussion=20
list.]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR><BR><BR></FONT></=
DIV></BODY></HTML>

------=_NextPart_000_00D2_01C29BAA.260B1000--

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]