Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-25 Thread Jamal Hadi Salim
On 16-02-25 04:46 PM, Daniel Borkmann wrote: On 02/25/2016 01:20 PM, Jamal Hadi Salim wrote: Let me think about it. Likely it will be subsequent patches - I just want to get this set out first. Yes, I mean one of the key motivation was "[...] to horizontally scale packet processing at scope

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-25 Thread John Fastabend
On 16-02-25 01:46 PM, Daniel Borkmann wrote: > On 02/25/2016 01:20 PM, Jamal Hadi Salim wrote: >> On 16-02-24 12:37 PM, Daniel Borkmann wrote: >>> On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim >>> [...] +static const struct nla_policy

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-25 Thread Daniel Borkmann
On 02/25/2016 01:20 PM, Jamal Hadi Salim wrote: On 16-02-24 12:37 PM, Daniel Borkmann wrote: On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim [...] +static const struct nla_policy ife_policy[TCA_IFE_MAX + 1] = { +[TCA_IFE_PARMS] = {.len =

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-25 Thread Jamal Hadi Salim
On 16-02-24 12:37 PM, Daniel Borkmann wrote: On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim [...] +static const struct nla_policy ife_policy[TCA_IFE_MAX + 1] = { +[TCA_IFE_PARMS] = {.len = sizeof(struct tc_ife)}, +[TCA_IFE_DMAC] = {.type =

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-24 Thread Cong Wang
On Wed, Feb 24, 2016 at 5:09 AM, Jamal Hadi Salim wrote: > On 16-02-23 04:44 PM, Cong Wang wrote: >> >> On Tue, Feb 23, 2016 at 4:49 AM, Jamal Hadi Salim >> wrote: > > >>> +#define MODULE_ALIAS_IFE_META(metan) MODULE_ALIAS("ifemeta" >>>

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-24 Thread Daniel Borkmann
On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim [...] +static const struct nla_policy ife_policy[TCA_IFE_MAX + 1] = { + [TCA_IFE_PARMS] = {.len = sizeof(struct tc_ife)}, + [TCA_IFE_DMAC] = {.type = NLA_BINARY,.len = ETH_ALEN}, +

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-24 Thread Jamal Hadi Salim
On 16-02-23 04:44 PM, Cong Wang wrote: On Tue, Feb 23, 2016 at 4:49 AM, Jamal Hadi Salim wrote: +#define MODULE_ALIAS_IFE_META(metan) MODULE_ALIAS("ifemeta" __stringify_1(metan)) + +int get_meta_u32(struct sk_buff *skb, struct tcf_meta_info *mi); +int

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-24 Thread Jamal Hadi Salim
On 16-02-23 11:12 AM, Daniel Borkmann wrote: On 02/23/2016 03:39 PM, Jamal Hadi Salim wrote: My question was rather: should the kernel enforce the IDs and only allow what the kernel dictates (and not in/out of tree modules)? If yes, then there would be no need for a module parameter (and the

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-24 Thread Jamal Hadi Salim
On 16-02-24 12:46 AM, Simon Horman wrote: On Tue, Feb 23, 2016 at 05:12:34PM +0100, Daniel Borkmann wrote: From my point of view the test should be weather the encapsulation might reasonably be expected to be used outside of the context of tc. If so then it makes sense to use a netdev to

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Simon Horman
On Tue, Feb 23, 2016 at 05:12:34PM +0100, Daniel Borkmann wrote: > On 02/23/2016 03:39 PM, Jamal Hadi Salim wrote: > >On 16-02-23 08:32 AM, Daniel Borkmann wrote: > >>On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: > >>>From: Jamal Hadi Salim > >>> > >>>This action allows for a

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Cong Wang
On Tue, Feb 23, 2016 at 4:49 AM, Jamal Hadi Salim wrote: > From: Jamal Hadi Salim > > This action allows for a sending side to encapsulate arbitrary metadata > which is decapsulated by the receiving end. > The sender runs in encoding mode and the receiver in

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Cong Wang
On Tue, Feb 23, 2016 at 8:12 AM, Daniel Borkmann wrote: > On 02/23/2016 03:39 PM, Jamal Hadi Salim wrote: >> >> On 16-02-23 08:32 AM, Daniel Borkmann wrote: >>> >>> On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Daniel Borkmann
On 02/23/2016 03:39 PM, Jamal Hadi Salim wrote: On 16-02-23 08:32 AM, Daniel Borkmann wrote: On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim This action allows for a sending side to encapsulate arbitrary metadata which is decapsulated by the

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Jamal Hadi Salim
On 16-02-23 08:32 AM, Daniel Borkmann wrote: On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim This action allows for a sending side to encapsulate arbitrary metadata which is decapsulated by the receiving end. The sender runs in encoding mode and the

Re: [net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Daniel Borkmann
On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: From: Jamal Hadi Salim This action allows for a sending side to encapsulate arbitrary metadata which is decapsulated by the receiving end. The sender runs in encoding mode and the receiver in decode mode. Both sender and

[net-next PATCH v2 1/5] introduce IFE action

2016-02-23 Thread Jamal Hadi Salim
From: Jamal Hadi Salim This action allows for a sending side to encapsulate arbitrary metadata which is decapsulated by the receiving end. The sender runs in encoding mode and the receiver in decode mode. Both sender and receiver must specify the same ethertype. At some point