On 21.06.2016 11:42, Tom Herbert wrote:
>> > There is also some argument to be had for theory versus application.
>> > Arguably it is the customers that are leading to some of the dirty
>> > hacks as I think vendors are building NICs based on customer use cases
>> > versus following any specificati
On Tue, Jun 21, 2016 at 11:17 AM, Alexander Duyck
wrote:
> On Tue, Jun 21, 2016 at 10:40 AM, Hannes Frederic Sowa
> wrote:
>> On 21.06.2016 10:27, Edward Cree wrote:
>>> On 21/06/16 18:05, Alexander Duyck wrote:
On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote:
> But anyways, the vas
On Tue, Jun 21, 2016 at 10:40 AM, Hannes Frederic Sowa
wrote:
> On 21.06.2016 10:27, Edward Cree wrote:
>> On 21/06/16 18:05, Alexander Duyck wrote:
>>> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote:
But anyways, the vastness of the key is why we want to keep "sockets"
out of netw
On 21/06/16 18:40, Hannes Frederic Sowa wrote:
> On 21.06.2016 10:27, Edward Cree wrote:
>> At a given physical point in the network, a given UDP flow either is or is
>> not carrying encapsulated traffic, and if it tries to be both then things
>> are certain to break, just as much as if two differe
On 21.06.2016 10:27, Edward Cree wrote:
> On 21/06/16 18:05, Alexander Duyck wrote:
>> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote:
>>> But anyways, the vastness of the key is why we want to keep "sockets"
>>> out of network cards, because proper support of "sockets" requires
>>> access to
On 21/06/16 18:05, Alexander Duyck wrote:
> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote:
>> But anyways, the vastness of the key is why we want to keep "sockets"
>> out of network cards, because proper support of "sockets" requires
>> access to information the card simply does not and shou
On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote:
> From: Tom Herbert
> Date: Mon, 20 Jun 2016 10:05:01 -0700
>
>> Generally, this means it needs to at least match by local addresses
>> and port for an unconnected/unbound socket, the source address for
>> an unconnected/bound socket, a the ful
On 21.06.2016 01:22, David Miller wrote:
> From: Tom Herbert
> Date: Mon, 20 Jun 2016 10:05:01 -0700
>
>> Generally, this means it needs to at least match by local addresses
>> and port for an unconnected/unbound socket, the source address for
>> an unconnected/bound socket, a the full 4-tuple fo
On 21/06/16 09:22, David Miller wrote:
> From: Tom Herbert Date: Mon, 20 Jun 2016 10:05:01 -0700
>> Generally, this means it needs to at least match by local addresses and port
>> for an unconnected/unbound socket, the source address for an
>> unconnected/bound socket, a the full 4-tuple for a c
From: Hannes Frederic Sowa
Date: Mon, 20 Jun 2016 11:11:32 -0700
> I am not sure if this is necessary. The devices actually having the
> ndo-ops, used to configure offloading, should only be visible inside one
> namespace. If those ndo-ops actually have side effects on other
> namespaces, they vi
From: Tom Herbert
Date: Mon, 20 Jun 2016 10:05:01 -0700
> Generally, this means it needs to at least match by local addresses
> and port for an unconnected/unbound socket, the source address for
> an unconnected/bound socket, a the full 4-tuple for a connected
> socket.
These lookup keys are all
On 20.06.2016 12:27, Tom Herbert wrote:
>> Do we?
>>
>> We look up the socket in a proper way, inclusive the namespace belonging
>> to the device we received the packet on. That said, I don't see a
>> problem with that right now. But maybe I miss something?
>>
> When we so the socket lookup in udp_
On Mon, Jun 20, 2016 at 2:36 PM, Hannes Frederic Sowa
wrote:
> On 20.06.2016 12:27, Tom Herbert wrote:
>>> Do we?
>>>
>>> We look up the socket in a proper way, inclusive the namespace belonging
>>> to the device we received the packet on. That said, I don't see a
>>> problem with that right now.
> Do we?
>
> We look up the socket in a proper way, inclusive the namespace belonging
> to the device we received the packet on. That said, I don't see a
> problem with that right now. But maybe I miss something?
>
When we so the socket lookup in udp_rcv this is done after IP layer
and packet has b
Hello,
On 20.06.2016 10:05, Tom Herbert wrote:
>> And finally, he added a big comment explaining that new tunnel types
>> should not be added to the tunnel type list, and those that exist
>> should only be used for RX.
>>
>> Therefore, this isn't openning the door for new random offloads, quite
>>
> And finally, he added a big comment explaining that new tunnel types
> should not be added to the tunnel type list, and those that exist
> should only be used for RX.
>
> Therefore, this isn't openning the door for new random offloads, quite
> the contrary. Instead, if it making clearer what the
From: Alexander Duyck
Date: Thu, 16 Jun 2016 12:20:35 -0700
> s patch is meant to address two things. First we are currently using
> the ndo_add/del_vxlan_port calls with VXLAN-GPE tunnels and we cannot
> really support that as it is likely to cause more harm than good since
> VXLAN-GPE can supp
s patch is meant to address two things. First we are currently using
the ndo_add/del_vxlan_port calls with VXLAN-GPE tunnels and we cannot
really support that as it is likely to cause more harm than good since
VXLAN-GPE can support tunnels without a MAC address on the inner header.
As such we nee
18 matches
Mail list logo
