> Please also tell me what legacy application could actually
> use this thing when BSD itself doesn't even implement it?
Some version of java seems to. I see a lot of:
ioctl32(java:30851): Unknown cmd fd(3) cmd(8938){00} arg(bfbb87c4) on
socket:[334628709]
But just rejecting it is probabl
"Ristuccia, Brian" <[EMAIL PROTECTED]> writes:
> I'm seeing a problem where the kernel attempts to send packets with a
> MSS larger than the one negotiated when the TCP connection is
> established. Even after ICMP "can't fragment" messages arrive, the
> kernel still attempts to increase the MSS ra
FYI,
While testing 2.6.21-git2 on a NFS root box and pulling the ethernet cable of
the NFS
server for a few seconds I got this
nfs: server 10.23.204.1 not responding, still trying
nfs: server 10.23.204.1 not responding, still trying
Dead loop on netdevice eth0, fix it urgently!
nfs: server 10
David Miller <[EMAIL PROTECTED]> writes:
>
> Unfortunately, as mentioned elsewhere, we're only able to assume
> 32-bit alignment of ipv6 packet headers and that isn't likely to
> change any time soon.
On x86 it would be fine at least -- unaligned access is cheap. I believe
the same is true for PO
Rick Jones <[EMAIL PROTECTED]> writes:
> Folks -
>
> Is it a bug, or a feature that after changing a device's smp_affinity
> via echo "N" >> /proc/irq/M/smp_affinity that the new mask isn't
> visible via cat /proc/irq/M/smp_affinity until after actual interrupts
> are taken?
Intel chipsets can o
ch should fix it.
-Andi
Report the pending irq if available in smp_affinity
Otherwise smp_affinity would only update after the next interrupt
on x86 systems.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
I
Krishna Kumar <[EMAIL PROTECTED]> writes:
> Doing some measurements, I found that for small packets like 128 bytes,
> the bandwidth is approximately 60% of the line speed. To possibly speed
> up performance of small packet xmits, a method of "linking" skbs was
> thought of - where two pointers (sk
On Fri, May 11, 2007 at 02:02:55PM +0530, Krishna Kumar2 wrote:
> Hi Andy,
>
> [EMAIL PROTECTED] wrote on 05/11/2007 02:35:05 PM:
>
> > You don't need that. You can just use the normal next/prev pointers.
> > In general it's a good idea to lower lock overhead etc., the VM has
> > used similar tri
On Friday 11 May 2007 13:16:44 Roland Dreier wrote:
> > I wasn't talking about sending.
> >
> > But there actually is :- TSO/GSO.
>
> As I said before, getting multiple packets in one call to xmit would
> be nice for amortizing per-xmit overhead in IPoIB. So it would be
> nice if the cases wh
On Wednesday 16 May 2007 17:37, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations (and
> >
Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> I would think a non-conditional deref would be easily pipelined.
> If the net_device struct was more cache dense, it probably would
> even out.
It might be a good idea to consider strategic prefetch points for it.
e.g. TCP executes quite a lot of
Kieran Mansley <[EMAIL PROTECTED]> writes:
> RCU on its own wouldn't
> prevent the accelerated plugin being unloaded while netfront was using
> one of the hooks.
Note that module unload does always does a stop_machine() which is much
stronger than normal RCU. As long as you don't sleep and cann
Ayaz Abdulla <[EMAIL PROTECTED]> writes:
> This patch fixes the power management functions. It includes lowering
> the phy speed to conserve power.
Shouldn't there be some way to disable this? AFAIK a few old switches
have trouble with this. I assume a new ethtool option would be appropiate
since
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> Hi.
>
> On Wed, Jul 18, 2007 at 11:51:03PM -0700, vinay ravuri ([EMAIL PROTECTED])
> wrote:
> > How about the following approach:
> >
> > I allocate an skb of 0 bytes and replace data element
> > of skb struct (i.e. skb.data = addr_given_by_hw) whe
FYI
Since -git15 (probably David's merge) I see a lot of
Virtual device lo asks to queue packet!
Virtual device lo asks to queue packet!
Virtual device lo asks to queue packet!
Virtual device lo asks to queue packet!
Virtual device lo asks to queue packet!
Virtual device lo asks to queue packet
David Miller <[EMAIL PROTECTED]> writes:
>
> Good candidates for taking advantage of multi-napi are:
>
> 1) e1000
> 2) ucc_geth
> 3) ehea
> 4) sunvnet
s2io.c
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
I tried to mount another nfs mount on a system running with nfsroot.
But I get
# mount basil:/home /basil/home/
mount: Network is down
The network is not down of course, the system is happily running with nfs root
from that
server. Userland is older SUSE 10.0
Excerpt from strace mount:
-Andi
On Saturday 21 July 2007 09:49:22 Andi Kleen wrote:
>
> FYI
>
> Since -git15 (probably David's merge) I see a lot of
>
> Virtual device lo asks to queue packet!
> Virtual device lo asks to queue packet!
> Virtual device lo asks to queue packet!
> Virtua
On Saturday 21 July 2007 20:53:04 David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Sat, 21 Jul 2007 09:49:22 +0200
>
> > Since -git15 (probably David's merge) I see a lot of
> >
> > Virtual device lo asks to queue packet!
> > Virtual
On Mon, Jul 23, 2007 at 10:58:22AM +0100, Stephen Hemminger wrote:
> On 21 Jul 2007 15:26:00 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > David Miller <[EMAIL PROTECTED]> writes:
> > >
> > > Good candidates for taking advantage of multi-napi
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> So "called once" should probably make the inlining weight bigger (ie
> inline *larger* functions than you would otherwise), it just shouldn't
> make it "infinite". It's not worth it.
There's probably a --param where it can be tweaked exactly. The
p
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> * Removed all multi-queue code
Why? With David's new multi NAPI work it will finally make sense, won't it?
-Andi (who would finally like to see a driver which is able to process
incoming packets and TX completion interrupts on multiple CPUs)
-
To unsub
Hallo,
I tried suspend to RAM on my desktop. Surprisingly near everything worked
after the wakeup, except for the pcnet32 PCI card. Kernel is 2.6.23-rc1-git4
on x86_64.
Bootup:
pcnet32.c:v1.33-NAPI 27.Jun.2006 [EMAIL PROTECTED]
IOAPIC[0]: Set routing entry (2-21 -> 0x81 -> IRQ 21 Mode:1 Active:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> All,
>
> Another update on e1000e. Many thanks to Jeff for helping out and
> getting this going forward. The driver is unfortunately still too
> large to post, so please use the URL's below to review:
Just some things I noticed; no comprehensive review
Jeff Garzik <[EMAIL PROTECTED]> writes:
> > + val, reg_index, addr, addr+4); */
> > + writel(cpu_to_le32(reg_index), addr);
> > + writel(cpu_to_le32(val),(u8 *)addr + 4);
>
> wrong -- endian conversion macros not needed with writel()
Are you sure? I don't think that's true.
[EMAIL PROTECTED] writes:
> NetEffect connection manager routines.
This seems more like a new TCP stack. I don't think such code
is appropiate, since Linux already has one.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > > + val, reg_index, addr, addr+4); */
> > > > +
On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > > > Jeff Gar
On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > > > On Wed, Au
On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
> Heiko Carstens wrote:
> >On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> >>From: Heiko Carstens <[EMAIL PROTECTED]>
> >>Date: Wed, 8 Aug 2007 11:33:00 +0200
> >>
> >>>Just saw this while grepping for atomic_reads in a wh
> Isn't it possible through some inline assembly trick
> that only a certain variable has to be reloaded?
A volatile cast does that already
-Andi
-
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.
On Fri, Aug 10, 2007 at 10:30:12AM -0400, jamal wrote:
> On Fri, 2007-10-08 at 16:02 +0200, Andi Kleen wrote:
> > On Fri, Aug 10, 2007 at 09:35:12AM -0400, jamal wrote:
>
> >
> > Affected in what way?
> >
>
> They dont get errors back and they just ke
On Fri, Aug 10, 2007 at 09:35:12AM -0400, jamal wrote:
>
> It seems there are a lot of dumbass apps (latest i have found is iperf
> when analyzing batching results) out there whose performance is affected
> if they dont set IP_RECVERR.
Affected in what way?
> If you set that option though you
On Friday 10 August 2007 10:21:46 Herbert Xu wrote:
> Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> >
> > The compiler is within its rights to read a 32-bit quantity 16 bits at
> > at time, even on a 32-bit machine. I would be glad to help pummel any
> > compiler writer that pulls such a dirty tri
"Ramkrishna Vepa" <[EMAIL PROTECTED]> writes:
> In one of the variations of this driver that is not
> released to netdev, the received packets are steered to a channel based
> on hashing on a preconfigured criteria such as sockets on tcp_ipv4,
> udp_ipv4, tcp_ipv6, udp_ipv6 or addresses in ipv4/6.
Shay Goikhman <[EMAIL PROTECTED]> writes:
> Dear Linux maintainers,
>
> I'm doing :
>
> setsockopt(s, SO_RCVTIMEO, t1 ); // set time-out
> t1 on socket while block receiving on it
> select(,,, &fd_set_including(s), .., &errs, t2); // block till
> receive or ti
On Friday 17 August 2007 05:42, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" generally screws up is
"Felix Marti" <[EMAIL PROTECTED]> writes:
> what benefits does the TSO infrastructure give the
> non-TSO capable devices?
It improves performance on software queueing devices between guests
and hypervisors. This is a more and more important application these
days. Even when the system running th
"Felix Marti" <[EMAIL PROTECTED]> writes:
> > avoidance gains of TSO and LRO are still a very worthwhile savings.
> So, i.e. with TSO, your saving about 16 headers (let us say 14 + 20 +
> 20), 864B, when moving ~64KB of payload - looks like very much in the
> noise to me.
TSO is beneficial for the
"Felix Marti" <[EMAIL PROTECTED]> writes:
> What I was referring to is that TSO(/LRO) have their own
> issues, some eluded to by Roland and me. In fact, customers working on
> the LSR couldn't use TSO due to the burstiness it introduces
That was in old kernels where TSO didn't honor the initial c
> GPUs have almost no influence on system security,
Unless you use direct rendering from user space.
-Andi
-
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
On Tue, Aug 21, 2007 at 07:33:49PM +1000, Paul Mackerras wrote:
> So the whole discussion is irrelevant to ARM, PowerPC and any other
> architecture except x86[-64].
It's even irrelevant on x86 because all modifying operations on atomic_t
are coded in inline assembler and will always be RMW no ma
On Friday 24 August 2007 13:59:32 Denys Vlasenko wrote:
> On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
> >
> > static inline void wait_for_init_deassert(atomic_t *deassert)
> > {
> > - while (!atomic_read(deassert));
> > + while (!atomic_read(deassert))
> > + cpu_relax();
David Miller <[EMAIL PROTECTED]> writes:
>
> 2) Switch the default qdisc away from pfifo_fast to a new DRR fifo
>with load balancing using the code in #1. I think this is kind
>of in the territory of what Peter said he is working on.
Hopefully that new qdisc will just use the TX rings of
> I wonder about the whole idea of queueing in general at such high speeds.
> Given the normal bi-modal distribution of packets, and the predominance
> of 1500 byte MTU; does it make sense to even have any queueing in software
> at all?
Yes that is my point -- it should just pass it through direct
On Tue, Oct 09, 2007 at 05:04:35PM -0700, David Miller wrote:
> We have to keep in mind, however, that the sw queue right now is 1000
> packets. I heavily discourage any driver author to try and use any
> single TX queue of that size.
Why would you discourage them?
If 1000 is ok for a softwar
> A 256 entry TX hw queue fills up trivially on 1GB and 10GB, but if you
With TSO really?
> increase the size much more performance starts to go down due to L2
> cache thrashing.
Another possibility would be to consider using cache avoidance
instructions while updating the TX ring (e.g. write c
On Wed, Oct 10, 2007 at 02:25:50AM -0700, David Miller wrote:
> The chip I was working with at the time (UltraSPARC-IIi) compressed
> all the linear stores into 64-byte full cacheline transactions via
> the store buffer.
That's a pretty old CPU. Conclusions on more modern ones might be different.
> We've done similar testing with ixgbe to push maximum descriptor counts,
> and we lost performance very quickly in the same range you're quoting on
> NIU.
Did you try it with WC writes to the ring or CLFLUSH?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
> Use RCU? or write a generic version and get it reviewed. You really
> want someone with knowledge of all the possible barrier impacts to
> review it.
I guess he was thinking of using cmpxchg; but we don't support this
in portable code.
RCU is not really suitable for this because it assume
writ
"Eliezer Tamir" <[EMAIL PROTECTED]> writes:
> * For now depend on x86 or x86_64, will add more architectures ASAP.
Why is that? Linux drivers normally should not be architecture specific.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
> related to this comment, does Linux have a lockless (using atomics)
> singly linked list element? That would be very useful in a driver hot
> path.
No; it doesn't. At least not a portable one.
Besides they tend to be not faster anyways because e.g. cmpxchg tends
to be as slow as an explicit spi
Matti Aarnio <[EMAIL PROTECTED]> writes:
>
> Undocumented are also IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP (RFC 2553 / 3493)
The IPv6 man page was never complete when I wrote it long ago.
This
BUGS
...
This man page is not complete.
is still true.
> It really looks like time for
> This is not a driver issue.
> Unfortunately, the firmware code is different for LE and BE machines.
> We had issues with the BE firmware that appear to be resolved.
> Hopefully, the next version will have both.
If the firmware is big it might be better to just add the necessary
conversions to th
On Mon, Oct 15, 2007 at 06:22:03PM +0200, Eliezer Tamir wrote:
> On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote:
> > > This is not a driver issue.
> > > Unfortunately, the firmware code is different for LE and BE machines.
> > > We had issues with the BE firmw
Yanping Du <[EMAIL PROTECTED]> writes:
> We found the standard 16-bit tcp checksum is not
> strong enough in some cases. Is there any roadmap on
> implementing RFC1146 (tcp alternative checksum
> options) in Linux tcp stack ?
The standard way to solve this problem is to either use
SSL or IPSec.
On Fri, Oct 26, 2007 at 05:21:31PM +0200, Jean Delvare wrote:
> I know that /proc/net/tcp is
> deprecated in favor of tcp_diag, however at the moment netstat only
> knows of the former.
Even tcp_diag will be slow when all slots are dumped. It's a fundamental
problem of the data structure. /proc ha
This particular problem has come up many times over the years. So far
the standard strategy has been to ignore it. It's doubtful that the
complexity needed for a fix is worth it.
Workaround at user space level: call shutdown() first instead of close()
-Andi
-
To unsubscribe from this list: send
> Next, machines that service that many sockets typically have them
> mostly with full transmit queues talking to a very slow receiver at
> the other end.
Not sure -- there are likely use cases with lots of idle but connected
sockets.
Also the constraint here is not really how many sockets are
On Thursday 01 November 2007 11:16:20 Eric Dumazet wrote:
Looks good from a quick look. Thanks for doing that work.
Some quick comments:
> +#if defined(CONFIG_SMP) || defined(CONFIG_PROVE_LOCKING)
> +/*
> + * Instead of using one rwlock for each inet_ehash_bucket, we use a table of
> locks
> +
> > Also the EHASH_LOCK_SZ == 0 special case is a little strange. Why did
> > you add that?
>
> He explained this in another reply, because ifdefs are ugly.
I meant why having it at all?
> Any use that makes
> "sense" is a case where the code should be rewritten to decrease the
> lock hold ti
> But I suspect distributions kernels enable CONFIG_HOTPLUG_CPU so
> num_possible_cpus() will be NR_CPUS.
Nope, on x86 num_possible_cpus() is derived from BIOS tables these days.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
On Sunday 04 November 2007 22:56:21 David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> This makes a huge different as we have to set NR_CPUS to 4096
> in order to handle the cpu numbering of some UltraSPARC-IV
> machines.
Really? Hopefully you have a large enough stac
"Matthew Faulkner" <[EMAIL PROTECTED]> writes:
> I'm probably being stupid and very confused here. Appologies if it is
> a stupid question.
>
> For a particular test I assign a client to core 1 and a server to core
> 0. My first assumption was all the sending side kernel TCP/IP
> processing will b
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> Rank 8: __change_page_attr
> BUG at arch/x86/mm/pageattr_64.c:176
> Reported 2 times
> Reported this week for 2.6.24-rc5; history goes back to 2.6.15
There is no BUG on this line on 2.6.24-rc5. Since there are many
BUG_ON
> in this case this is really all the version information available ;(
> it seems to be a patched kernel without patched EXTRAVERSION.
> But in the future if I have more specific information (eg it's only 1
> kernel version) I'll mention it in more detail.
> It gets unwieldy if there's 500 reports
Al Viro <[EMAIL PROTECTED]> writes:
>
> Checksum is fixed-endian and we want it that way; IOW, what we end up
> storing in skb->csum should be fixed-endian as well.
AFAIK skb->csum is always native endian because it normally
needs to be manipulated further even for RX.
-Andi
--
To unsubscribe fro
"Andy Johnson" <[EMAIL PROTECTED]> writes:
> Can anybody give an example when hh_cache of a neighbour instance is a
> list with more than
> one entry ?
When you're talking to the same host on a local ethernet with both native IPv4
and native IPv6.
-Andi
--
To unsubscribe from this list: send th
On Sun, Dec 30, 2007 at 05:12:05PM +0200, Andy Johnson wrote:
> Can there be a case in such environment (using IPv4 only) where
> hh_cache of a neighbour instance is a
> list with more than one entry ?
In theory if some device supplies own multiple dst_ops with different
protocol numbers. From a
David Miller <[EMAIL PROTECTED]> writes:
> From: James Chapman <[EMAIL PROTECTED]>
> Date: Sat, 05 Jan 2008 00:18:31 +
>
>> David Miller wrote:
>> > From: James Chapman <[EMAIL PROTECTED]>
>> > Date: Fri, 04 Jan 2008 20:10:30 +
>> >
>> >> With the latest NAPI, this code has to change. But
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> Rank 4: remove_proc_entry
> Was also ranked 4th last week
> Only in tainted oopses
> Reported 3 times (12 total reports)
> More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Likely a broken module_exit()
On Sat, Jan 05, 2008 at 07:31:29PM -0800, Arjan van de Ven wrote:
> Andi Kleen wrote:
> >Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >>Rank 4: remove_proc_entry
> >>Was also ranked 4th last week
> >>Only in tainted oopses
> >>Re
David Miller <[EMAIL PROTECTED]> writes:
> Similarly I question just about any inline usage at all in *.c files
Don't forget the .h files. Especially a lot of stuff in tcp.h should
be probably in some .c file and not be inline.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe n
On Mon, Jan 07, 2008 at 05:54:58PM -0800, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 08 Jan 2008 01:23:11 +0100
>
> > David Miller <[EMAIL PROTECTED]> writes:
> >
> > > Similarly I question just about any inline usage at all
> % awk ' { line++ } ; /^{/ { start = line } ; /^}/ { n++; r += line-start-2;
> } ; END { print r/n }' < include/net/tcp.h
> 9.48889
>
> The average function length is 9 lines.
Actually 8 -- the awk hack had a off by one. Still too long.
-Andi
--
To unsubscribe from this list: send the line "
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 8 Jan 2008 03:05:29 +0100
>
> > On Mon, Jan 07, 2008 at 05:54:58PM -0800, David Miller wrote:
> > > I explicitly left them out.
> > >
> >
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> I usually just compile a small program like
Just use scripts/decodecode and cat the Code line into that.
> particularly good way to do it, and the old "ksymoops" program used to do
> a pretty good job of this, but I'm used to that particular idiotic
David Miller <[EMAIL PROTECTED]> writes:
>
> The big problem is that recovery from even a single packet loss in a
> window makes us run kfree_skb() for a all the packets in a full
> window's worth of data when recovery completes.
Why exactly is it a problem to free them all at once? Are you worrie
> It adds severe spikes in CPU utilization that are even moderate
> line rates begins to affect RTTs.
>
> Or do you think it's OK to process 500,000 SKBs while locked
> in a software interrupt.
You can always push it into a work queue. Even put it to
other cores if you want.
In fact this is al
> Postponing freeing of the skb has major drawbacks. Some time ago I
Yes, the trick would be to make sure that it also does not tie up
too much memory. e.g. it would need some throttling at least.
Also the fast path of kmem_cache_free() is actually not that
much different from just putting someth
Vince Fuller <[EMAIL PROTECTED]> writes:
> from Vince Fuller <[EMAIL PROTECTED]>
>
> This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
> (aka "class-E") address space as consistent with the Internet Draft
> draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait for
> I think it should be in netdev_unregister_kobject(). But that would
> only get rid of one of the two calls to synchronize_rcu() in the
> unregister_netdev.
Would be already an improvement.
> The other synchronize_rcu() is for qdisc's and not sure if that one can
> be removed?
The standard w
"Ilpo Järvinen" <[EMAIL PROTECTED]> writes:
>
> Besides, it not always that obvious that gcc is able to determine "the
> constant state", considering e.g., the complexity in the cases with
> tcp_rcv_synsent_state_process, tcp_close_state, tcp_done. In such cases
> uninlining should be done and gcc
My workstation running 2.6.24-rc8 just hung during shutdown with an endless
(or rather I didn't wait more than a few minutes) loop of
unregister_netdev: waiting for ppp-device to become free. Usage count = 1
ppp-device was an active PPPoE device.
No more information currently.
-Andi
--
To un
> It seems to have stopped when i stopped using ipsec and started using
> vpnc.
Kernel ipsec was active yes. However I normally don't see it although
it is often active, that was the first time I think
(except long ago)
> (but no firm info - this was sporadic - happened every few months
> or
Sreenivasa Honnur <[EMAIL PROTECTED]> writes:
> Multiqueue netwrok device support implementation.
> - Added a loadable parameter "multiq" to enable/disable multiqueue support,
> by default it is disabled.
> - skb->queue_mapping is not used for queue/fifo selection. FIFO iselection is
> based o
> [Ram] I am assuming that this is with regards to msi-x interrupts. We
Yes.
And avoiding bouncing locks for device state between CPUs.
> have done away with handling tx completion in the interrupt handler, and
> are instead handling them in the context of the transmit. The slow path,
> straggl
"Ivan H. Dichev" <[EMAIL PROTECTED]> writes:
>
> What could happen if I put different Lan card in every slot?
> In ex. to-private -> 3com
> to-inet-> VIA
> to-dmz -> rtl8139
> And then to look which RX function is consuming the memory.
> (boomerang_rx, rtl8139_rx, ... etc)
The
> > There are two ways to fix the warnings:
> >
> > 1. get rid of the thunks and call the C functions directly; or
>
> No. Not until gcc learns about per-function callibg conventions (so that it
> can
> be marked as not clobbering registers).
It does already for static functions in 5.x (with -fi
Shanker Wang writes:
> This patch removes the check for CAP_NET_ADMIN in the initial namespace
> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user
> namespace the net namespace was created so that /dev/ppp cat get opened
> in a unprivileged container.
Seems dangerous. From a
Tom Herbert writes:
> Also, we don't do anything special for alignment, unaligned
> accesses on x86 do not appear to be a performance issue.
This is not true on Atom CPUs.
Also on most CPUs there is still a larger penalty when crossing
cache lines.
> Verified correctness by testing arbitrary l
Al Viro <[EMAIL PROTECTED]> writes:
>
> Incidentally, WTF is
> define SK_CS_CALCULATE_CHECKSUM
> #ifndef CONFIG_X86_64
> #define SkCsCalculateChecksum(p,l) ((~ip_compute_csum(p, l)) & 0x)
> #else
> #define SkCsCalculateChecksum(p,l) ((~ip_fast_csum(p, l)) & 0x)
> #endif
> in .
On Tuesday 14 November 2006 09:49, Gerrit Renker wrote:
> [UDP]: Reduce size of shared code
>
> This patch reduces size of source code files by moving
> some of the smaller functions shared by UDP and UDP-Lite
> into the header file udp_impl.h, and in-lining these.
>
> It is an optimisation and a
On Tuesday 14 November 2006 20:38, Williams, Mitch A wrote:
> Hi folks, I'm looking for some suggestions for software that uses
> the kernel's netpoll interface to receive packets. The only in-kernel
> application that uses netpoll right now is netconsole, and that only
> sends packets.
There are
> before i go opening bugs with the distribution folks, could someone chime
> in as to what is the recommended approach these days? did grat arp fall
> out of favour, or is it just a case of userland not keeping up?
The ifup script in iproute2 does it in user land, but nobody uses it
directly
> 64-bit x86_64:
> [0.509409] test_siphash: SipHash2-4 cycles: 4049181
> [0.510650] test_siphash: SipHash1-3 cycles: 2512884
> [0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920
> [0.512904] test_siphash:JenkinsHash cycles: 978267
I'm not sure what these numbers m
> Bear with me, I'm a software guy :) I interpret that to mean that the
> processor is basically broken? If so, wouldn't it be the case that
> prefetch() needs to become a noop on that processor?
I would agree with Rick - if prefetch() is broken on Xscale it should be
disabled
in the archite
On Wednesday 07 June 2006 11:39, Linsys Contractor Amit S. Kale wrote:
> + switch (mode) {
... You could save a lot of code by using a table and a loop over the registers.
> + case 4:{/* XGB Mode */
> + NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_SINGLE_
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume
> Well the DSL modem only transfers whatever data the ISP end sends to it,
> which in your case is just PPP packets (LCC or LCP I think). No one out
> on the internet
No one out on the internet, but it would be trivial for someone outside
his house. All his traffic will be on a long unsecured c
101 - 200 of 579 matches
Mail list logo
