Re: Network stack/ethernet driver issues
Re: Network stack/ethernet driver issues
- Subject: Re: Network stack/ethernet driver issues
- From: "Justin C. Walker" <email@hidden>
- Date: Thu, 10 Apr 2008 22:12:00 -0700
On Apr 10, 2008, at 10:35 , Michael Cashwell wrote:
On Apr 10, 2008, at 11:44 AM, Justin C. Walker wrote:
On Apr 10, 2008, at 06:45 , Michael Cashwell wrote:
The point in rimas' case is that just because the data are UDP
does not give the Ethernet driver more permission to drop them
than if they were TCP [corrected] nor does it mean they are less
important.
You are correct that an ethernet driver does not have permission to
drop one kind of packet over another, I don't think you are correct
in your implication that it cares about network-layer packet types
Did I imply it does? I didn't intend to.
You did say that the driver should not have "more permission" to drop
UDP over TCP packets. I don't know of any driver that pays attention
to IP frame type (in particular because they can't always tell; as you
say, fragmentation is fun).
: these are all one to the driver (it's possible for the driver to
obey QOS indicators of some type, but it can't know about the IP
frame type: in particular, it may not know that a particular packet
is in fact (part of) a UDP frame). After all, it's ethernet. Even
if the packet gets to the media layer, there's no guarantee that
(a) it will make it out the door; or (b) even if it gets out the
door, it may not survive the trip across the local link :-}).
Fragmentation is fun. :-)
I don't think TCP/UDP or QoS is involved in rimas' problem. That
really does look like a driver issue.
I don't think so, although I suppose it's worth looking at. The
driver can only do so much; it's part of a bucket brigade, and if it
doesn't have buffers, that's it for the outgoing packets. The driver
has no clue where the packets come from; it's just all bits to it.
My point was only to underscore that there are different dimensions
to the question of what delivery characteristics are most important.
If you're transferring live video having data arrive late is no
different from it not arrive at all. In fact, if "late" requires
retries and resends (and this consumed even more bandwidth and
resources) only to just be dropped anyway then late is actually
worse than not at all.
You are certainly correct, but the driver isn't involved in that.
Assuming that someone's data is less important just because they
used UDP is flawed.
I don't think there is any assumption regarding that except in the UDP
code, where it's assumed that if there's no space for the packet, it's
OK to drop it.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden