>> a competing philosophy that said that the IP checksum must be
>> recomputed incrementally at routers to catch hardware problems in the
...
>ah.. we do recalculate IP Checksums now.. when we update any of the
>timestamp rr options etc..
But, do you do it incrementally? By which I
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote:
> On Mon, 26 Feb 2001, David S. Miller wrote:
> > At gigapacket rates, it becomes an issue. This guy is talking about
> > tinkering with new IP _options_, not just the header. So even if the
> > IP header itself fits totally in a cache line, the
On Mon, 26 Feb 2001, David S. Miller wrote:
> > Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave
> > :) and was looking at 4.2.2.6 where it mentions that a router MUST
> > implement the End of Option List option.. Havent' figured out where
> > that is implememented
On Mon, 26 Feb 2001, Craig Milo Rogers wrote:
> > > I have a whole 40 bytes (+/-) to share... Now although I don't see
> > > anything explicitly prohibiting the use of unused IP Header option
..
> > > in between.. Has anyone seen any RFC that explicitly says I MUST NOT?
> >
> >Not to my
On Mon, 26 Feb 2001, David S. Miller wrote:
> At gigapacket rates, it becomes an issue. This guy is talking about
> tinkering with new IP _options_, not just the header. So even if the
> IP header itself fits totally in a cache line, the options afterwardsd
> likely will not and thus require
Benjamin C.R. LaHaise writes:
> Since the ip header fits in the cache of some CPUs (like the P4),
> this becoming a cheaper operation than ever before.
At gigapacket rates, it becomes an issue. This guy is talking about
tinkering with new IP _options_, not just the header. So even if the
IP
On Mon, 26 Feb 2001, David S. Miller wrote:
> Not to my knowledge. Routers already change the time to live field,
> so I see no reason why they can't do smart things with special IP
> options either (besides efficiency concerns :-).
A number of ISPs patch the MSS value to 1492 due to the
Michael Peddemors writes:
> A few things.. why is ip.h not part of the linux/include/net rather than
> linux/include/linux hierachy?
Exported to older userlands...
> Defined items that are not used anywhere in the source..
> Can any of them be deleted now?
>
So what, userland makes use
Michael Peddemors <[EMAIL PROTECTED]> writes:
> A few things.. why is ip.h not part of the linux/include/net rather than
> linux/include/linux hierachy?
Because it needs to be user visible for raw sockets (linux is exported to the user,
net isn't)
> Defined items that are not used anywhere
While doing some work on some ip options stuff, I have noticed a bunchof
unused entries in linux/include/linux/ip.h
A few things.. why is ip.h not part of the linux/include/net rather than
linux/include/linux hierachy?
Defined items that are not used anywhere in the source..
Can any of them
While doing some work on some ip options stuff, I have noticed a bunchof
unused entries in linux/include/linux/ip.h
A few things.. why is ip.h not part of the linux/include/net rather than
linux/include/linux hierachy?
Defined items that are not used anywhere in the source..
Can any of them
Michael Peddemors [EMAIL PROTECTED] writes:
A few things.. why is ip.h not part of the linux/include/net rather than
linux/include/linux hierachy?
Because it needs to be user visible for raw sockets (linux is exported to the user,
net isn't)
Defined items that are not used anywhere in the
On Mon, 26 Feb 2001, Craig Milo Rogers wrote:
I have a whole 40 bytes (+/-) to share... Now although I don't see
anything explicitly prohibiting the use of unused IP Header option
..
in between.. Has anyone seen any RFC that explicitly says I MUST NOT?
Not to my knowledge. Routers
Benjamin C.R. LaHaise writes:
Since the ip header fits in the cache of some CPUs (like the P4),
this becoming a cheaper operation than ever before.
At gigapacket rates, it becomes an issue. This guy is talking about
tinkering with new IP _options_, not just the header. So even if the
IP
a competing philosophy that said that the IP checksum must be
recomputed incrementally at routers to catch hardware problems in the
...
ah.. we do recalculate IP Checksums now.. when we update any of the
timestamp rr options etc..
But, do you do it incrementally? By which I mean:
On Mon, 26 Feb 2001, David S. Miller wrote:
Not to my knowledge. Routers already change the time to live field,
so I see no reason why they can't do smart things with special IP
options either (besides efficiency concerns :-).
A number of ISPs patch the MSS value to 1492 due to the
On Mon, 26 Feb 2001, David S. Miller wrote:
At gigapacket rates, it becomes an issue. This guy is talking about
tinkering with new IP _options_, not just the header. So even if the
IP header itself fits totally in a cache line, the options afterwardsd
likely will not and thus require
On Mon, 26 Feb 2001, David S. Miller wrote:
Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave
:) and was looking at 4.2.2.6 where it mentions that a router MUST
implement the End of Option List option.. Havent' figured out where
that is implememented yet..
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote:
On Mon, 26 Feb 2001, David S. Miller wrote:
At gigapacket rates, it becomes an issue. This guy is talking about
tinkering with new IP _options_, not just the header. So even if the
IP header itself fits totally in a cache line, the
19 matches
Mail list logo
