[EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Thu, 21 Jun 2007 13:08:12 -0600
However this just seems to allow a card to decode multiple mac
addresses which in some oddball load balancing configurations may
actually be useful, but it seems fairly limited.
Do
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael S. Tsirkin
Sent: Tuesday, January 09, 2007 5:57 AM
To: Steve Wise
Cc: netdev@vger.kernel.org; Roland Dreier; Divy Le Ray;
linux-kernel@vger.kernel.org; openib-general
Subject: Re:
On 10/12/06, Rick Jones [EMAIL PROTECTED] wrote:
Martin Schiller wrote:
Hi!
I'm searching for a solution to suppress / delay the SYN-ACK packet of a
listening server (-application) until he has decided (e.g. analysed the
requesting ip-address or checked if the corresponding other end of a
[EMAIL PROTECTED] wrote:
Finally, as I understand both network isolation and network
virtualization (both level2 and level3) can happily co-exist. We do
have several filesystems in kernel. Let's have several network
virtualization approaches, and let a user choose. Is that makes
sense?
[EMAIL PROTECTED] wrote:
From: Steve Wise [EMAIL PROTECTED]
Date: Wed, 05 Jul 2006 12:50:34 -0500
However, iWARP devices _could_ integrate with netfilter. For most
devices the connection request event (SYN) gets passed up to the host
driver. So the driver can enforce filter rules then.
[EMAIL PROTECTED] wrote:
From: Tom Tucker [EMAIL PROTECTED]
Date: Wed, 05 Jul 2006 12:09:42 -0500
A TOE net stack is closed source firmware. Linux engineers have no
way to fix security issues that arise. As a result, only non-TOE
users will receive security updates, leaving random windows
[EMAIL PROTECTED] wrote:
Evgeniy Polyakov wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear
([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am
Andi Kleen wrote:
We're focusing on netfilter here. Is breaking netfilter really the
only issue with this stuff?
Another concern is that it will just not be able to keep
up with a high rate of new connections or a high number of them
(because the hardware has too limited state)
Neither
Herbert Xu wrote:
Yes, however I think the same argument could be applied to TOE.
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
[EMAIL PROTECTED] wrote:
From: Steve Wise [EMAIL PROTECTED]
Date: Wed, 28 Jun 2006 09:54:57 -0500
Doesn't iSCSI have this same issue?
Software iSCSI implementations don't have the issue because
they go through the stack using normal sockets and normal
device send and receive.
But
Jeff Garzik wrote:
Caitlin Bestler wrote:
Jeff Garzik wrote:
Caitlin Bestler wrote:
But hardware iSCSI implementations, which already exist, do not
work through normal sockets.
No, they work through normal SCSI stack...
Correct.
But they then interface to the network using none
[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 dst_entry
[EMAIL PROTECTED] wrote:
On Thu, 2006-22-06 at 15:40 -0500, Steve Wise wrote:
On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
No - what these 2 gents are saying was these events and
infrastructure already exist.
Notification of the exact events needed does not exist today.
Ok, so you
[EMAIL PROTECTED] wrote:
On Thu, 2006-22-06 at 15:58 -0500, Steve Wise wrote:
On Thu, 2006-06-22 at 16:36 -0400, jamal wrote:
I created a new notifier block in my patch for these network events.
I guess I thought I was using the existing infrastructure to provide
this notification service.
[EMAIL PROTECTED] wrote:
On Thu, 2006-06-15 at 08:41 -0500, Steve Wise wrote:
On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
+void c2_ae_event(struct c2_dev *c2dev, u32 mq_index) {
+
snip
+ case C2_RES_IND_EP:{
+
+ struct c2wr_ae_connection_request *req =
+
[EMAIL PROTECTED] wrote:
On Tue, 2006-06-13 at 16:46 -0500, Steve Wise wrote:
On Tue, 2006-06-13 at 14:36 -0700, Sean Hefty wrote:
Er...no. It will lose this event. Depending on the event...the
carnage varies. We'll take a look at this.
This behavior is consistent with the Infiniband CM
There's a difference between trying to handle the user calling
disconnect/destroy at the same time a call to accept/connect is
active, versus the user calling disconnect/destroy after
accept/connect have returned. In the latter case, I think you're
fine. In the first case, this is
[EMAIL PROTECTED] wrote:
On Thu, 25 May 2006 13:23:50 -0700 (PDT) David Miller
[EMAIL PROTECTED] wrote:
From: #ZHOU BIN# [EMAIL PROTECTED]
Date: Thu, 25 May 2006 16:30:48 +0800
Yes, I agree. Actually the main contribution of TCP Veno is not in
this AI phase. No matter the ABC is added
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller
Sent: Tuesday, May 02, 2006 11:48 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: VJ Channel API - driver level (PATCH)
Are you proposing a mechanism for the consuming end of a tx
channel to support a large number of channels, or are you
assuming that the number of tx channels will be small enough
that simply polling them in priority order is adequate?
-
To unsubscribe from this list: send the line unsubscribe
Evgeniy Polyakov wrote:
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load balancing), as well as explicit 1:1
steering between a sw channel and a hw channel. Both
David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Wed, 3 May 2006 22:07:40 +0400
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load balancing
Evgeniy Polyakov wrote:
On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
So the real issue is when there is an intelligent device that uses
hardware packet classification to place the packet in the correct
ring. We don't want to bypass packet filtering
Evgeniy Polyakov wrote:
On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
Btw, how is it supposed to work without header split capabale
hardware?
Hardware that can classify packets is obviously capable of doing
header data separation, but that does
Evgeniy Polyakov wrote:
I see your point, and respectfully disagree.
The more complex userspace interface we create the less users
it will have. It is completely unconvenient to read 100 bytes
and receive only 80, since 20 were eaten by header. And what
if we need only 20, but packet
David S. Miller wrote:
From: Rusty Russell [EMAIL PROTECTED]
Date: Sat, 29 Apr 2006 08:04:04 +1000
You're still thinking you can bypass classifiers for established
sockets, but I really don't think you can. I think the simplest
solution is to effectively remove from (or flag) the
[EMAIL PROTECTED] wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Thu, 27 Apr 2006 15:51:26 +0400
There are some caveats here found while developing zero-copy sniffer
[1]. Project's goal was to remap skbs into userspace in real-time.
While absolute numbers (posted to netdev@) were
[EMAIL PROTECTED] wrote:
Ok I have comments already just glancing at the initial patch.
With the 32-bit descriptors in the channel, you indeed end up
with a fixed sized pool with a lot of hard-to-finesse sizing
and lookup problems to solve.
So what I wanted to do was finesse the entire
David S. Miller wrote:
I personally think allowing sockets to trump firewall rules
is an acceptable relaxation of the rules in order to simplify
the implementation.
I agree. I have never seen a set of netfilter rules that
would block arbitrary packets *within* an established connection.
Jeff Garzik wrote:
Caitlin Bestler wrote:
David S. Miller wrote:
I personally think allowing sockets to trump firewall rules is an
acceptable relaxation of the rules in order to simplify the
implementation.
I agree. I have never seen a set of netfilter rules that would block
arbitrary
David S. Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 26 Apr 2006 15:46:58 -0400
Oh, there are plenty of examples of filtering within an established
connection: input rules. I've seen drop all packets from these
IPs type rules frequently. Victims of DoS use those kinds of
[EMAIL PROTECTED] wrote:
From: Caitlin Bestler [EMAIL PROTECTED]
Date: Wed, 26 Apr 2006 15:53:44 -0700
The netchannel qualifiers should only deal with TCP packets for
established connections. Listens would continue to be dealt with by
the existing stack logic, vj_channelizing only occurring
[EMAIL PROTECTED] wrote:
Subject: Re: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sean Hefty
Sent: Monday, March 06, 2006 11:04 AM
To: 'Roland Dreier'
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
openib-general@openib.org
Subject: [PATCH 2/6] IB: match connection
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Stevens
Sent: Monday, March 06, 2006 11:49 AM
To: Michael S. Tsirkin
Cc: Linux Kernel Mailing List; netdev@vger.kernel.org
Subject: Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
I
-Original Message-
From: David Stevens [mailto:[EMAIL PROTECTED]
Sent: Monday, March 06, 2006 12:32 PM
To: Caitlin Bestler
Cc: Linux Kernel Mailing List; Michael S. Tsirkin;
netdev@vger.kernel.org
Subject: RE: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
IPPROTO_* should
[EMAIL PROTECTED] wrote:
Below patch wasn't even compile tested. I'm not involved
with network drivers anymore, so my personal interest is
fairly low. But since I firmly believe in the advantages and
feasibility of interrupt-less TX, there should at least be an
ugly broken patch to flame
Generally there are two cases to consider: when the TCP mode is not visible
and when it is.
When it is not visible it is certainly easy to manage the TCP connection
with subset logic within the RDMA stack and never involve the host
stack. This is certainly what the initial proposal will rely
38 matches
Mail list logo
