Benjamin Reed wrote:
I think Mark's point isn't about "atomic" writes;
instead, he was pointing out that when a programmer
reads that a call is thread-safe he usually
understands that to mean that it does not need to be
protected by a lock when used by multiple threads.
This thread-safe iss
I've been asked a couple of questions by our engineering guys.
1) Is there any inherent limit on the number of IP addresses that can be
configured on an interface?
2) Is there any inherent limit on the number of subnets that a linux
host can have configured at any given time?
If anyone cou
David S. Miller wrote:
From: Jon DeVree <[EMAIL PROTECTED]>
I've noticed in the past that the address owned by an interface is
still pingable after that interface is brought down.
People bring this up all the time and this behavior is
intentional.
This is becoming a serious FAQ and very
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
This was discussed on the netdev list, and the conclusion was that
you want both NAPI and hw mitigation. This was implemented in a
few drivers, at least.
How does that deal with the latency that hw mitigation introduces.
When
David S. Miller wrote:
He wants to go the other direction, from socket to file descriptor.
Typically people doing this are implementing desktop notifiers for
socket activity and stuff like that in order to fill in a feature
checkbox that Windows happens to have...
I believe in this case it's
Jesse Brandeburg wrote:
On 1/18/06, Christopher Friesen <[EMAIL PROTECTED]> wrote:
So, somehow we're getting into a state where we can't receive packets,
and we're never getting out of that state.
Are you sure that you're able to transmit and you aren't just
Jesse Brandeburg wrote:
On 1/18/06, Christopher Friesen <[EMAIL PROTECTED]> wrote:
just so you've got all the latest bug fixes can you try the driver
from http://prdownloads.sf.net/e1000/e1000-6.3.9.tar.gz
I'll try that.
So, somehow we're getting into a state w
We're seeing an issue with an e1000 device. After some time (4-8 hrs
typically) it jams itself up and refuses to receive any more packets.
We're running 2.6.10, but with the e1000 driver from 2.6.14.
Outgoing packets seem to be fine, incoming packets just increment the
error count.
ethtoo
Herbert Xu wrote:
As I said before, you should not rely on getpid() to work.
You should always use getsockaddr(2) to get your local address.
Should that be getsockname(2)? Anyways, I now understand the issues.
As it turns out, we were actually already calling getsockname() a bit
earlier
Alexey Kuznetsov wrote:
Hello!
I tend to agree with you here that tgid makes more sense.
I agree, apparently netlink_autobind was missed when sed'ing pid->tgid.
Of course, it does not matter, but tgid is nicer choice from user's viewpoint.
I'm glad you agree, but I'm not sure what you mea
Friesen, Christopher [CAR:VC21:EXCH] wrote:
When using netlink, should "nlmsg_pid" be set to pid (current->tgid) or
tid (current->pid)?
The reason I ask is that with 2.6.10 we had to set it to tid, which
really doesn't make much sense given than sockets are shared across all
threads in a pr
When using netlink, should "nlmsg_pid" be set to pid (current->tgid) or
tid (current->pid)?
Chris
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov wrote:
Couple of numbers...
Remapping of the physical page took about 25-50% less time than 1500
bytes copying using memcpy().
Presumably as packet size decreases, at some point the memcpy() becomes
cheaper. With your hardware, where is this crossover point?
Chris
-
To unsu
13 matches
Mail list logo
