Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1200397 > unrolled thread

Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive() Joe Stringer <joestringer@nicira.com> - 2015-08-05 06:50 +0200
    Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive() Jesse Gross <jesse@nicira.com> - 2015-08-08 00:10 +0200

#1200397 — Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()

On 1 August 2015 at 12:17, Thomas Graf <tgraf@suug.ch> wrote:
> On 07/31/15 at 10:51am, Joe Stringer wrote:
>> On 31 July 2015 at 07:34, Hannes Frederic Sowa <hannes@redhat.com> wrote:
>> > In general, this shouldn't be necessary as the packet should already be
>> > scrubbed before they arrive here.
>> >
>> > Could you maybe add a WARN_ON and check how those skbs with conntrack
>> > data traverse the stack? I also didn't understand why make it dependent
>> > on the socket.
>>
>> OK, sure. One case I could think of is with an OVS internal port in
>> another namespace, directly attached to the bridge. I'll have a play
>> around with WARN_ON and see if I can come up with something more
>> trimmed down.
>
> The OVS internal port will definitely pass through an unscrubbed
> packet across namespaces. I think the proper thing to do would be
> to scrub but conditionally keep metadata.

It's only "unscrubbed" when receiving from local stack at the moment.
Some pieces are cleared when handing towards the local stack, and
there's no configuration for that behaviour. Presumably internal port
transmit and receive should mirror each other?

I don't have a specific use case either way. The remaining code for
this series handles this case correctly, it's just a matter of what
behaviour we're looking for. We could implement the flag as you say, I
presume that userspace would need to specify this during vport
creation and the default should work similar to the existing behaviour
(ie, keep metadata). One thing that's not entirely clear to me is
exactly which metadata should be represented by this flag and whether
the single flag is expressive enough.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1203051

On Tue, Aug 4, 2015 at 9:40 PM, Joe Stringer <joestringer@nicira.com> wrote:
> On 1 August 2015 at 12:17, Thomas Graf <tgraf@suug.ch> wrote:
>> On 07/31/15 at 10:51am, Joe Stringer wrote:
>>> On 31 July 2015 at 07:34, Hannes Frederic Sowa <hannes@redhat.com> wrote:
>>> > In general, this shouldn't be necessary as the packet should already be
>>> > scrubbed before they arrive here.
>>> >
>>> > Could you maybe add a WARN_ON and check how those skbs with conntrack
>>> > data traverse the stack? I also didn't understand why make it dependent
>>> > on the socket.
>>>
>>> OK, sure. One case I could think of is with an OVS internal port in
>>> another namespace, directly attached to the bridge. I'll have a play
>>> around with WARN_ON and see if I can come up with something more
>>> trimmed down.
>>
>> The OVS internal port will definitely pass through an unscrubbed
>> packet across namespaces. I think the proper thing to do would be
>> to scrub but conditionally keep metadata.
>
> It's only "unscrubbed" when receiving from local stack at the moment.
> Some pieces are cleared when handing towards the local stack, and
> there's no configuration for that behaviour. Presumably internal port
> transmit and receive should mirror each other?
>
> I don't have a specific use case either way. The remaining code for
> this series handles this case correctly, it's just a matter of what
> behaviour we're looking for. We could implement the flag as you say, I
> presume that userspace would need to specify this during vport
> creation and the default should work similar to the existing behaviour
> (ie, keep metadata). One thing that's not entirely clear to me is
> exactly which metadata should be represented by this flag and whether
> the single flag is expressive enough.

I would prefer not to have a flag as it seems unnecessarily
complicated (doubly so if we try to have multiple flags to express
different combinations). The use case for moving internal ports to
different namespaces is pretty narrow, so it seems like we can just
pick a set of metadata to keep and go with that. Mark seems the
primary one to me.

I also think that it would be better to use skb->dev to determine the
original namespace rather than the socket.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web