Sam Vilain <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> In general it is possible to get file descriptors opened by someone
>> else because unix domain sockets allow file descriptor passing. Similarly
>> I think there are cases in both unshare and fork that allows you to sockets
>> o
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 28 Jun 2006 15:35:54 +1000
> With their RDMA NIC, we'll have TCP/SCTP connections that bypass
> netfilter, tc, IPsec, AF_PACKET/tcpdump and the rest of our stack
> while at the same time it is using the same IP address as us and
> deciding what packe
Eric W. Biederman wrote:
> Have a few more network interfaces for a layer 2 solution
> is fundamental. Believing without proof and after arguments
> to the contrary that you have not contradicted that a layer 2
> solution is inherently slower is non-productive. Arguing
> that a layer 2 only solut
Eric W. Biederman wrote:
> In general it is possible to get file descriptors opened by someone
> else because unix domain sockets allow file descriptor passing. Similarly
> I think there are cases in both unshare and fork that allows you to sockets
> open before you entered a namespace.
>
This
On Tue, Jun 27, 2006 at 10:33:48PM -0600, Eric W. Biederman wrote:
>
> Something to examine here is that if both network devices and sockets
> are tagged does that still allow implicit network namespace passing.
I think avoiding implicit network namespace passing expresses more
power/flexibility
Hi,
Minor fix (un-export selinux_get_sock_sid()).
thanks,
Catherine
--
From: [EMAIL PROTECTED]
This patch implements an API whereby an application can determine the
label of its peer's Unix datagram sockets via the auxiliary data mechanism of
recvmsg.
Patch purpose:
This patch enables a se
On Tue, Jun 27, 2006 at 09:43:23PM -0700, David Miller wrote:
>
> Socket state, and that is one thing I don't see them doing yet.
I wonder what happens when the Linux TCP stack attempts to open a
connection to a remote host when that connection is already open
in the RDMA NIC? For that matter wh
Hi Cris,
I'm looking to decrease the interrupt load on the system. During the
test I mentioned above I had some interesting and confusing results.
The changes from the default settings to the settings I posted resulted
in a 100% performance increase (counted by the number of VoIP audio
streams
On Tue, Jun 27, 2006 at 09:54:39PM -0700, Michael Chan wrote:
>
> Assuming that we'll later have GSO_TCPV6, isn't it better to check for
> TCPV4 explicitly now? Or just change it later when necessary.
Good point, I suppose you never know whether a V6 TSO-capable card is going
to handle ECN correc
On Wed, 2006-06-28 at 14:42 +1000, Herbert Xu wrote:
> On Tue, Jun 27, 2006 at 09:37:01PM -0700, Michael Chan wrote:
> > @@ -56,6 +55,9 @@ static inline void TCP_ECN_send(struct s
> > if (tp->ecn_flags&TCP_ECN_QUEUE_CWR) {
> > tp->ecn_flags &= ~TCP_E
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 28 Jun 2006 14:29:59 +1000
> On Wed, Jun 28, 2006 at 12:18:25AM -0400, Jeff Garzik wrote:
> >
> > A PCI device that presents itself as a SCSI controller, but under the
> > hood is really iSCSI-over-TCP smells like TOE. Running a virtualized
> > L
On Tue, Jun 27, 2006 at 09:37:01PM -0700, Michael Chan wrote:
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Looks good to me too!
> @@ -56,6 +55,9 @@ static inline void TCP_ECN_send(struct s
> if (tp->ecn_flags&TCP_ECN_QUEUE_CWR) {
> tp->
Herbert Xu wrote:
On Wed, Jun 28, 2006 at 12:18:25AM -0400, Jeff Garzik wrote:
A PCI device that presents itself as a SCSI controller, but under the
hood is really iSCSI-over-TCP smells like TOE. Running a virtualized
Linux guest on top of a proprietary stack [which provides networking
servic
On Wed, 2006-06-28 at 13:48 +1000, Herbert Xu wrote:
> I think you're mixing up GSO the mechanism with GSO the flag. The GSO
> flag simply tells the TCP stack whether TSO should be used or not, even
> if the hardware does not support TSO at all. The GSO mechanism on the
> other hand is ALWAYS pr
Sam Vilain <[EMAIL PROTECTED]> writes:
> It sounds then like it would be a good start to have general socket
> namespaces, if it would merge more easily - perhaps then network device
> namespaces would fall into place more easily.
I guess I really see both sockets and devices as the fundamental
On Wed, Jun 28, 2006 at 12:18:25AM -0400, Jeff Garzik wrote:
>
> A PCI device that presents itself as a SCSI controller, but under the
> hood is really iSCSI-over-TCP smells like TOE. Running a virtualized
> Linux guest on top of a proprietary stack [which provides networking
> services to gue
Andrey Savochkin <[EMAIL PROTECTED]> writes:
> Eric,
>
> On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>>
>> Thinking about this I am going to suggest a slightly different direction
>> for get a patchset we can merge.
>>
>> First we concentrate on the fundamentals.
>> - How
Herbert Xu wrote:
On Tue, Jun 27, 2006 at 11:24:25PM -0400, Jeff Garzik wrote:
I don't see how that position has changed?
http://linux-net.osdl.org/index.php/TOE
Well I must say that RDMA over TCP smells very much like TOE. They've
got an ARP table, a routing table, and presumably a TCP stac
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Tue, Jun 27, 2006 at 10:29:39AM -0600, Eric W. Biederman wrote:
>> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
>> I watched the linux-vserver irc channel for a while and almost
>> every network problem was caused by the change in semantics
>> vserv
On Tue, Jun 27, 2006 at 08:40:34PM -0700, Michael Chan wrote:
>
> We need to turn off NETIF_F_TSO for a connection that has negotiated to
> turn on ECN if the output device cannot handle TSO and ECN. In other
> words, if the output device does not have either GSO or TSO_ECN feature
> set.
I think
On Wed, 2006-06-28 at 13:10 +1000, Herbert Xu wrote:
> On Tue, Jun 27, 2006 at 08:06:47PM -0700, Michael Chan wrote:
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 2d8d6ad..2c75172 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -1033,7 +1033,8 @@ sta
Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
> Hello!
>
>> It may look weird, but do application really *need* to see eth0 rather
>> than eth858354?
>
> Applications do not care, humans do. :-)
>
> What's about applications they just need to see exactly the same device
> after migration. Not only
On Tue, Jun 27, 2006 at 11:24:25PM -0400, Jeff Garzik wrote:
>
> I don't see how that position has changed?
>
> http://linux-net.osdl.org/index.php/TOE
Well I must say that RDMA over TCP smells very much like TOE. They've
got an ARP table, a routing table, and presumably a TCP stack.
Cheers,
--
Herbert Xu wrote:
On Wed, Jun 28, 2006 at 12:54:10PM +1000, Herbert Xu wrote:
Please give more specific reasons for needing these events because it
is certainly far from obvious from reading those documents.
Never mind, I've found your earlier messages on the list which explains
your reasons m
On Tue, Jun 27, 2006 at 08:06:47PM -0700, Michael Chan wrote:
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 2d8d6ad..2c75172 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1033,7 +1033,8 @@ static inline void sk_setup_caps(struct
> if (sk->sk_route_caps
Add NETIF_F_TSO_ECN feature for all bnx2 hardware.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 7635736..e89d5df 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5128,6 +5128,16 @@ bnx2_set_rx_csum(struct net_device *dev,
In the current TSO implementation, NETIF_F_TSO and ECN cannot be
turned on together in a TCP connection. The problem is that most
hardware that supports TSO does not handle CWR correctly if it is set
in the TSO packet. Correct handling requires CWR to be set in the
first packet only if it is set
On Wed, Jun 28, 2006 at 12:54:10PM +1000, Herbert Xu wrote:
>
> Please give more specific reasons for needing these events because it
> is certainly far from obvious from reading those documents.
Never mind, I've found your earlier messages on the list which explains
your reasons more clearly. I
Steve Wise <[EMAIL PROTECTED]> wrote:
>
> The reason these devices need update events is because they typically
> cache this information in hardware and need to be notified when this
> information has been updated. For information on RDMA protocols, see:
> http://www.ietf.org/html.charters/rddp-c
Got it. Will send a new patch soon.
Catherine
James Morris <[EMAIL PROTECTED]> wrote on 06/27/2006 10:13:48 PM:
> On Tue, 27 Jun 2006, Xiaolan Zhang wrote:
>
> > > Just one more thing, we don't need to export this function now.
> >
> > You mean moving it to security/selinux/hooks.c and making
On Tue, 27 Jun 2006, James Morris wrote:
> > I think conceptually this is where it should reside -- auditing system
> > might need it in the future, for example.
>
> We can export it then.
To clarify, we can export it if the audit system needs it, in the future.
- James
--
James Morris
<[EM
On Tue, 27 Jun 2006, Xiaolan Zhang wrote:
> > Just one more thing, we don't need to export this function now.
>
> You mean moving it to security/selinux/hooks.c and making it static?
Yep.
> I think conceptually this is where it should reside -- auditing system
> might need it in the future, fo
On Wed, 2006-06-28 at 08:31 +1000, Herbert Xu wrote:
> [NET]: Fix logical error in skb_gso_ok
>
> The test in skb_gso_ok is backwards. Noticed by Michael Chan
> <[EMAIL PROTECTED]>.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Acked-by: Michael Chan <[EMAIL PROTECTED]>
-
To unsubscribe f
On Mon, Jun 26, 2006 at 04:59:24AM +0200, Lennert Buytenhek wrote:
> The cirrus ep93xx is an ARM SoC that includes an ethernet MAC --
> this patch adds a driver for that ethernet MAC.
Attached is a new version that optimises interrupt handling somewhat.
Since we clear RX status as the first thing
James Morris <[EMAIL PROTECTED]> wrote on 06/27/2006 09:33:17 PM:
> On Tue, 27 Jun 2006, Catherine Zhang wrote:
>
> > diff -puN security/selinux/exports.c~lsm-secpeer-unix
> security/selinux/exports.c
> > --- linux-2.6.17-rc6-mm2-JM/security/selinux/exports.c~lsm-
> secpeer-unix 2006-06-27 18:
On Tue, 27 Jun 2006, Catherine Zhang wrote:
> diff -puN security/selinux/exports.c~lsm-secpeer-unix
> security/selinux/exports.c
> --- linux-2.6.17-rc6-mm2-JM/security/selinux/exports.c~lsm-secpeer-unix
> 2006-06-27 18:15:10.914669944 -0400
> +++ linux-2.6.17-rc6-mm2-JM-cxzhang/security/se
Hi,
This patch combines all previous updates. Many thanks to James, Dave,
and Stephen for their modifications and comments!
cheers,
Catherine
--
From: [EMAIL PROTECTED]
This patch implements an API whereby an application can determine the
label of its peer's Unix datagram sockets via the aux
On Mon, Jun 26, 2006 at 05:25:52PM -0400, John W. Linville wrote:
> Michael Buesch:
> bcm43xx: suspend MAC while executing long pwork
The above patch ruffled some feathers on netdev. In the interest of
moving things along, I have pulled that patch out of wireless-2.6.
I expect it will be b
Hello!
> It may look weird, but do application really *need* to see eth0 rather
> than eth858354?
Applications do not care, humans do. :-)
What's about applications they just need to see exactly the same device
after migration. Not only name, but f.e. also its ifindex. If you do not
create a sep
Kiran Thota <[EMAIL PROTECTED]> :
[...]
> +/*
> + * Allocate the SKBs for the Rx ring. Also used
> + * for refilling the queue
> + */
> +
> +static int msp85x0_ge_rx_task(struct net_device *netdev,
> + msp85x0_ge_port_info *msp85x0_ge_eth)
> +{
> + struct device *de
On Wed, 2006-06-28 at 00:52 +0200, Herbert Poetzl wrote:
> seriously, what I think Eric meant was that it
> might be nice (especially for migration purposes)
> to keep the device namespace completely virtualized
> and not just isolated ...
It might be nice, but it is probably unneeded for an initi
On Tue, Jun 27, 2006 at 10:29:39AM -0600, Eric W. Biederman wrote:
> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
> > On Tue, Jun 27, 2006 at 01:54:51PM +0400, Kirill Korotaev wrote:
> >> >>My point is that if you make namespace tagging at routing time, and
> >> >>your packets are being routed onl
Modify the net/Kconfig file to enable selecting the NetLabel Kconfig options.
---
net/Kconfig |2 ++
1 files changed, 2 insertions(+)
Index: linux-2.6.17.i686-quilt/net/Kconfig
===
--- linux-2.6.17.i686-quilt.orig/net/Kconfig
+++
Add unlabeled packet support to the NetLabel subsystem. NetLabel does not do
any processing on unlabled packets, but it must support passing unlabled
packets on both the inbound and outbound sides.
---
net/netlabel/netlabel_unlabeled.c | 258 ++
1 files change
An updated patch set with some small changes as well as one big one - NetLabel
now uses the generic netlink interface for it's kernel-userland communication
as opposed to it's own dedicated netlink type. Needless to say this requires
an updated userland configuration tool, so for those of you runn
Add NetLabel support to the SELinux LSM and modify the socket_post_create() LSM
hook to return an error code. The most significant part of this patch is the
addition of NetLabel hooks into the following SELinux LSM hooks:
* selinux_file_permission()
* selinux_socket_sendmsg()
* selinux_socket_
Documentation for the NetLabel system, this includes a basic overview of how
NetLabel works and how LSM developers can integrate it into their favorite
LSM. Also, due to the difficulty of finding expired IETF drafts, I am
including the IETF CIPSO draft that is the basis of the NetLabel CIPSO
imple
Add support for the Commercial IP Security Option (CIPSO) to the IPv4 network
stack. CIPSO has become a de-facto standard for trusted/labeled networking
amongst existing Trusted Operating Systems such as Trusted Solaris, HP-UX CMW,
etc. This implementation is designed to be used with the NetLabel
Add CIPSO/IPv4 support and management to the NetLabel subsystem. These changes
integrate the CIPSO/IPv4 configuration into the existing NetLabel code and
enable the use of CIPSO/IPv4 within the overall NetLabel framework.
---
net/netlabel/netlabel_cipso_v4.c | 634 +++
Changes to the core network stack to support the NetLabel subsystem. This
includes changes to the IPv4 option handling to support CIPSO labels, and a new
NetLabel hook in inet_accept() to handle NetLabel attributes across a
accept()s done by in-kernel daemons.
---
include/linux/ip.h |1
Jeff,
after comments I've made some adjustments. I'll list them below against the
old summary. The changes are available from our git-server:
Please pull from:
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
These patches are against
netdev-2.6#upstream 612eff0e3715a6faff5ba1
On Tue, Jun 27, 2006 at 09:07:38AM -0700, Ben Greear wrote:
> Ben Greear wrote:
> >Herbert Poetzl wrote:
> >
> >>On Mon, Jun 26, 2006 at 03:13:17PM -0700, Ben Greear wrote:
> >
> >>yes, that sounds good to me, any numbers how that
> >>affects networking in general (performance wise and
> >>memory w
On Tue, Jun 27, 2006 at 10:19:23AM -0700, Ben Greear wrote:
> Eric W. Biederman wrote:
> >Herbert Poetzl <[EMAIL PROTECTED]> writes:
> >
> >
> >>On Tue, Jun 27, 2006 at 05:52:52AM -0600, Eric W. Biederman wrote:
> >>
> >>>Inside the containers I want all network devices named eth0!
> >>
> >>huh? ev
On Tue, Jun 27, 2006 at 09:31:57AM -0500, Steve Wise wrote:
>
> > I'd like to know more about what the RDMA device is going to do with this
> > information. I thought RDMA was for receiving packets? Most of the info
> > here pertains to transmission.
>
> RDMA Ethernet devices adhere to a set of
Andrey Savochkin wrote:
> On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>
>> Thinking about this I am going to suggest a slightly different direction
>> for get a patchset we can merge.
>>
>> First we concentrate on the fundamentals.
>> - How we mark a device as belonging to
On Tue, Jun 27, 2006 at 01:46:35PM -0700, Michael Chan wrote:
> On Tue, 2006-06-27 at 22:07 +1000, Herbert Xu wrote:
>
> > [NET]: Added GSO header verification
> >
> > @@ -2166,10 +2166,14 @@ struct sk_buff *tcp_tso_segment(struct s
> > if (!pskb_may_pull(skb, thlen))
> > g
Round 3 Changes:
- changed netlink msg for neighbour change to (RTM_NEIGHUPD)
- added netlink msg for PMTU change events (RTM_ROUTEUPD)
- added netlink messages for redirect (RTM_DELROUTE + RTM_NEWROUTE)
- tested neighbour change events via netlink for ipv4 and ipv6.
- tested redirect change even
This patch uses notifier blocks to implement a network event
notifier mechanism.
Clients register their callback function by calling
register_netevent_notifier() like this:
static struct notifier_block nb = {
.notifier_call = my_callback_func
};
...
register_netevent_notifier(&nb);
---
This patch adds netevent and netlink calls for neighbour change, route
add/del, pmtu change, and routing redirect events.
Netlink Details:
Neighbour change events are broadcast as a new ndmsg type RTM_NEIGHUPD.
Path mtu change events are broadcast as a new rtmsg type RTM_ROUTEUPD.
Routing redi
On Tue, 2006-06-27 at 22:07 +1000, Herbert Xu wrote:
> [NET]: Added GSO header verification
>
> @@ -2166,10 +2166,14 @@ struct sk_buff *tcp_tso_segment(struct s
> if (!pskb_may_pull(skb, thlen))
> goto out;
>
> + segs = NULL;
> + if (skb_gso_ok(skb, features |
Michael Buesch wrote:
On Tuesday 27 June 2006 22:06, Larry Finger wrote:
John,
I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why
I'm writing to you privately. Michael is correct in that the loop in question will not usually delay
private?
I
From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 15:33:19 -0500
> From my experimentation with netlink, RTM_NEWROUTE and RTM_DELROUTE
> messages do not get sent up for redirect events. I have, in fact, added
> this with the new patch I'll send out soon. So either way I need to
> chang
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2006 10:38:17 -0700
> On Thu, 2006-06-22 at 10:50 +1000, Herbert Xu wrote:
> > Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
> > >>
> > >> What about using the same fields (rqueue/wqueue) as you did for /proc?
> > >
> > > I meant exten
From: Shuya MAEDA <[EMAIL PROTECTED]>
Date: Wed, 21 Jun 2006 09:16:03 +0900
> Thank you for the comment.
> I made the patch that used the loop instead of the divide and modulus.
> Are there any comments?
Your email client has corrupted the patch, turning tab characters
into spaces, and also turni
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 21 Jun 2006 09:49:38 +1000
> [NET]: Make illegal_highdma more anal
>
> Rather than having illegal_highdma as a macro when HIGHMEM is off, we
> can turn it into an inline function that returns zero. This will catch
> callers that give it bad argumen
On Tue, 2006-06-27 at 13:21 -0700, David Miller wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Tue, 27 Jun 2006 15:19:08 -0500
>
> > For an RDMA NIC, all this logic is in HW, which is why we need the event
> > notification; to tell the HW to change its next hop information.
>
> Back to the
[EMAIL PROTECTED] wrote:
> From: Steve Wise <[EMAIL PROTECTED]>
> Date: Tue, 27 Jun 2006 10:02:19 -0500
>
>> For the RDMA kernel subsystem, however, we still need a specific
>> event. We need both the old and new dst_entry struct ptrs to figure
>> out which active connections were using the old ds
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 22:07:14 +1000
> This feature is only needed by Xen but most of the code here is useful
> for other things like TCPv4 ECN support.
>
> [NET]: Added GSO header verification
Looks sane, applied.
Thanks Herbert.
-
To unsubscribe from this
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 17:07:27 +0200
> * Thomas Graf <[EMAIL PROTECTED]> 2006-06-26 16:54
> > This patchset transforms skb->input_dev based on a device
> > reference to skb->iif based on an interface index moving
> > towards accurate iif information for routi
From: Stephen Smalley <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2006 13:19:05 -0400
> This patch encapsulates the usage of eff_cap (in netlink_skb_params) within
> the security framework by extending security_netlink_recv to include a
> required
> capability parameter and converting all direct usage
From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 10:02:19 -0500
> For the RDMA kernel subsystem, however, we still need a specific event.
> We need both the old and new dst_entry struct ptrs to figure out which
> active connections were using the old dst_entry and should be updated to
>
On Tuesday 27 June 2006 22:06, Larry Finger wrote:
> John,
>
> I would like to find a diplomatic solution to this impasse between Michael
> and Jeff, which is why
> I'm writing to you privately. Michael is correct in that the loop in question
> will not usually delay
private?
> long; however
On Tue, 2006-06-27 at 13:14 -0700, David Miller wrote:
> This change isn't truly atomic from a kernel standpoint either.
>
> The new dst won't be selected by the socket until later,
> when the socket tries to send something, notices the old dst
> is obsolete, and looks up a new one.
>
> Your code
From: Steve Wise <[EMAIL PROTECTED]>
Date: Tue, 27 Jun 2006 15:19:08 -0500
> For an RDMA NIC, all this logic is in HW, which is why we need the event
> notification; to tell the HW to change its next hop information.
Back to the route change notification, I still think you can
get what you need b
Michael Buesch wrote:
On Tuesday 27 June 2006 21:33, John W. Linville wrote:
On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
Michael Buesch wrote:
So, I will submit a patch to lower the udelay(10) to udelay(1)
and we can close
On Tuesday 27 June 2006 21:33, John W. Linville wrote:
> On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> > On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > > Michael Buesch wrote:
> > > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > > and we can close
On Mon, Jun 26, 2006 at 08:33:57PM -0400, James Morris wrote:
> On Mon, 26 Jun 2006, Joe Nall wrote:
> > For all of the EAL4 LSPP Linux evaluation work is being done by Red
> > Hat/IBM/HP/atsec and others to be useful to integrators, there has to be
> > basic
> > (e.g. CIPSO) multilevel network in
On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > Michael Buesch wrote:
> > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > and we can close the discussion? ;)
> >
> > No, that totally avoids my point. Yo
As many people don't seem to like the locking "obfuscation"
in the bcm43xx driver, this patch removes it.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2
Rick Jones wrote:
>
> Are you looking to increase or decrease the settings? I would think
> (initially at least) that for VOIP one might not want to increase them.
>
> rick jones
I'm looking to decrease the interrupt load on the system. During the
test I mentioned above I had some interesting and
Chris A. Icide wrote:
I've been digging around trying to get some information on the
current status of interrupt mitigation features for a Braodcom 5704 interface.
Specifically I'm sending and receiving lots of VoIP packets (50 pps
> per stream, many streams).
What I can't seem to determine i
Linas Vepstas wrote:
On Fri, Jun 23, 2006 at 01:07:21PM -0700, Auke Kok wrote:
Linas Vepstas wrote:
Minor janitorial patch: use #defines for literal values.
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ pci_enable_wake(pdev, PCI_D3cold, 0);
I Acked this but that's silly - the patches sen
Eric,
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>
> Thinking about this I am going to suggest a slightly different direction
> for get a patchset we can merge.
>
> First we concentrate on the fundamentals.
> - How we mark a device as belonging to a specific network names
On Tue, 2006-06-27 at 10:16 -0700, Chris A. Icide wrote:
> What version of the linux kernel & tg3 drivers are required to support both
> rx and tx mitigation?
ethtool -C for tg3 was added around July of 2005. The version with this
change added was 3.33.
> What do the ethtool coalescence setting
On Fri, Jun 23, 2006 at 01:07:21PM -0700, Auke Kok wrote:
> Linas Vepstas wrote:
> >Minor janitorial patch: use #defines for literal values.
> >+pci_enable_wake(pdev, PCI_D3hot, 0);
> >+pci_enable_wake(pdev, PCI_D3cold, 0);
>
> I Acked this but that's silly - the patches sent yesterday alr
Russell Stuart wrote:
> Without seeing your actual proposal it is difficult to
> judge whether this is a reasonable trade-off or not.
> Hopefully we will see your code soon. Do you have any
> idea when?
Probably not today, I'll try to get it into shape until tomomorrow.
-
To unsubscribe from this
I've been digging around trying to get some information on the current status
of interrupt mitigation features for a Braodcom 5704 interface.
Specifically I'm sending and receiving lots of VoIP packets (50 pps per stream,
many streams).
What I can't seem to determine is this:
What version of t
Eric W. Biederman wrote:
Herbert Poetzl <[EMAIL PROTECTED]> writes:
On Tue, Jun 27, 2006 at 05:52:52AM -0600, Eric W. Biederman wrote:
Inside the containers I want all network devices named eth0!
huh? even if there are two of them? also tun?
I think you meant, you want to be able to have
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
- How we mark a socket as belonging to a specific network namespace.
As part of
On Tue, Jun 27, 2006 at 06:02:42PM +0200, Herbert Poetzl wrote:
> - loopback traffic inside a guest is insignificantly
>slower than on a normal system
>
> - loopback traffic on the host is insignificantly
>slower than on a normal system
>
> - inter guest traffic is faster than on-wire
Kirill Korotaev <[EMAIL PROTECTED]> writes:
> This doesn't support anything. e.g. I caught quite a lot of bugs after Ingo
> Molnar, but this doesn't make his code "poor". People are people.
> Anyway, I would be happy to see the typo.
Look up thread. You replied to the message where I commented o
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in the field, for loops that can
> potentially lock the CPU for a long time upon hardware fault. And then
> there are the huge delays in specific functions that I pointed out...
>
> J
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Tue, Jun 27, 2006 at 05:52:52AM -0600, Eric W. Biederman wrote:
>>
>> Inside the containers I want all network devices named eth0!
>
> huh? even if there are two of them? also tun?
>
> I think you meant, you want to be able to have eth0 in
> _more_
Some more fixes:
> diff -purN -X dontdiff linux-2.6.o/net/unix/af_unix.c linux-2.6.
> w/net/unix/af_unix.c
> --- linux-2.6.o/net/unix/af_unix.c 2006-06-21 00:02:30.0 -0400
> +++ linux-2.6.w/net/unix/af_unix.c 2006-06-27 09:30:12.0 -0400
> @@ -128,6 +128,28 @@ static atomic_t u
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Tue, Jun 27, 2006 at 01:09:11PM +0400, Andrey Savochkin wrote:
>>
>> I'd like to caution about over-optimizing communications between
>> different network namespaces. Many optimizations of local traffic
>> (such as high MTU) don't look so appealing
On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> Michael Buesch wrote:
> > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > and we can close the discussion? ;)
>
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in t
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Tue, Jun 27, 2006 at 01:54:51PM +0400, Kirill Korotaev wrote:
>> >>My point is that if you make namespace tagging at routing time, and
>> >>your packets are being routed only once, you lose the ability
>> >>to have separate routing tables in each nam
On Tuesday 27 June 2006 18:10, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> >> Overall, bcm43xx is _really really bad_ about this sort of thing. Just
> >> grepping for udelay in bcm43xx_radio.c shows some of the worst
> >> offenders. bcm43xx
Hi,
Thanks for the updates. I am testing the code now. Some minor fixes (so
far):
changed all
#ifdef CONFIG_SECURITY_NETWORKING
to
#ifdef CONFIG_SECURITY_NETWORK
cheers,
Catherine
James Morris <[EMAIL PROTECTED]> wrote on 06/27/2006 09:57:15 AM:
> On Tue, 27 Jun 2006, Stephen Smalley wr
Jeff Garzik wrote:
Kok, Auke wrote:
This implements the core new functions needed for ich8's internal
NIC. This includes:
* ich8 specific read/write code
* flash/nvm access code
* software semaphore flag functions
* 10/100 PHY (fe - no gigabit speed) support for low-end versions
* A workaround
1 - 100 of 170 matches
Mail list logo
