[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
> -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: R
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
[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
>>
[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 rando
[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 rule
[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
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)
>
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..
Jeff Garzik wrote:
> Caitlin Bestler wrote:
>> [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 implem
[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.
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 deci
[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
[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
[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.
[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) {
+
>>
>>
>>
+ case C2_RES_IND_EP:{
+
+ struct c2wr_ae_connection_re
[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
>>
>> 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, thi
[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 matte
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 steeri
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"
>
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 net
[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
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
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
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
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
[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@
[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
>>
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
>> IPs" type rules frequently. Victims of DoS use those k
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.
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.
[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 ent
[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 o
> -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 IPPR
> -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
>
> -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 conn
[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 flam
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 upon.
39 matches
Mail list logo
