* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jamal Hadi Salim @ 2014-12-04 13:17 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417683438-10935-2-git-send-email-jiri@resnulli.us>
On 12/04/14 03:57, Jiri Pirko wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> include/linux/if_link.h | 1 +
> ip/ipaddress.c | 8 ++++++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 4732063..a6e2594 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -145,6 +145,7 @@ enum {
> IFLA_CARRIER,
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> + IFLA_PHYS_SWITCH_ID,
> __IFLA_MAX
> };
>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch iproute2 3/6] bridge/fdb: add flag/indication for FDB entry synced from offload device
From: Jamal Hadi Salim @ 2014-12-04 13:19 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417683438-10935-4-git-send-email-jiri@resnulli.us>
On 12/04/14 03:57, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
Did i say i like it already?;->
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [patch iproute2 4/6] bridge/link: add new offload hwmode swdev
From: Jamal Hadi Salim @ 2014-12-04 13:23 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417683438-10935-5-git-send-email-jiri@resnulli.us>
On 12/04/14 03:57, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To support full-featured switch devices offloading bridge funtionality,
> add new hwmode 'swdev'. Like 'vepa' and 'veb', 'swdev' indicated bridge
> port functionality is being offloaded to hardware.
>
Unhappy with the name swdev ..
Ok, go ahead and beat up on me.
cheers,
jamal
^ permalink raw reply
* Re: [patch iproute2 6/6] bridge/link: add learning_sync policy flag
From: Jamal Hadi Salim @ 2014-12-04 13:26 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417683438-10935-7-git-send-email-jiri@resnulli.us>
On 12/04/14 03:57, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> Add 'learned_sync' flag to turn on/off syncing of learned FDB entries from
> offload device to bridge's FDB. Flag would be set/cleared in on SELF using
> hwmode qualifier 'swdev'. E.g.:
>
> $ sudo bridge link set dev swp1 hwmode swdev learning_sync on
>
> $ bridge -d link show dev swp1
> 2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
> hairpin off guard off root_block off fastleave off learning off flood off
> 2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
> learning on learning_sync on hwmode swdev
>
> Adds new IFLA_BRPORT_LEARNING_SYNC attribute for IFLA_PROTINFO on the SELF
> brport.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I actually dont think any of these patches needed an ack because they
are off. My ack is just to show support (despite the noun challenges).
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net] net: sctp: use MAX_HEADER for headroom reserve in output path
From: Neil Horman @ 2014-12-04 13:41 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, linux-sctp, netdev, robert
In-Reply-To: <1417605238-9936-1-git-send-email-dborkman@redhat.com>
On Wed, Dec 03, 2014 at 12:13:58PM +0100, Daniel Borkmann wrote:
> To accomodate for enough headroom for tunnels, use MAX_HEADER instead
> of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
> of trinity an skb_under_panic() via SCTP output path (see reference).
> I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
> in other protocols might be one possible cause for this.
>
> In any case, it looks like accounting on chunks themself seems to look
> good as the skb already passed the SCTP output path and did not hit
> any skb_over_panic(). Given tunneling was enabled in his .config, the
> headroom would have been expanded by MAX_HEADER in this case.
>
> Reported-by: Robert Święcki <robert@swiecki.net>
> Reference: https://lkml.org/lkml/2014/12/1/507
> Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/output.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 42dffd4..fc5e45b 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -401,12 +401,12 @@ int sctp_packet_transmit(struct sctp_packet *packet)
> sk = chunk->skb->sk;
>
> /* Allocate the new skb. */
> - nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC);
> + nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
> if (!nskb)
> goto nomem;
>
> /* Make sure the outbound skb has enough header room reserved. */
> - skb_reserve(nskb, packet->overhead + LL_MAX_HEADER);
> + skb_reserve(nskb, packet->overhead + MAX_HEADER);
>
> /* Set the owning socket so that we know where to get the
> * destination IP address.
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Andy Gospodarek @ 2014-12-04 13:56 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal@
In-Reply-To: <54805EB6.2010901@mojatatu.com>
On Thu, Dec 04, 2014 at 08:16:38AM -0500, Jamal Hadi Salim wrote:
>
> General comment:
> iproute2 patches need to be addressed to the maintainer
> stephen@networkplumber.org
> And are we mainstream enough now we can drop the 1000 people on the
> To: list? I doubt most of these people are even following the discussion (I
> planted an easter egg for Aviad and didnt see him
> reacting) ;->
I actually don't mind them coming here since it is a change to netlink.
Thanks for sending them to netdev, Jiri.
>
> cheers,
> jamal
>
> On 12/04/14 03:57, Jiri Pirko wrote:
> >Jiri Pirko (1):
> > iproute2: ipa: show switch id
> >
> >Scott Feldman (5):
> > bridge/fdb: fix statistics output spacing
> > bridge/fdb: add flag/indication for FDB entry synced from offload
> > device
> > bridge/link: add new offload hwmode swdev
> > link: add missing IFLA_BRPORT_PROXYARP
> > bridge/link: add learning_sync policy flag
> >
> > bridge/fdb.c | 4 +++-
> > bridge/link.c | 17 +++++++++++++++--
> > include/linux/if_bridge.h | 1 +
> > include/linux/if_link.h | 3 +++
> > include/linux/neighbour.h | 1 +
> > ip/ipaddress.c | 8 ++++++++
> > man/man8/bridge.8 | 19 ++++++++++++++-----
> > 7 files changed, 45 insertions(+), 8 deletions(-)
> >
>
^ permalink raw reply
* Re: FIXME in solos-pci.c
From: chas williams - CONTRACTOR @ 2014-12-04 14:05 UTC (permalink / raw)
To: nick, Guy Ellis; +Cc: linux-atm-general, netdev, linux-kernel
In-Reply-To: <547FDBF6.5020008@gmail.com>
The last I heard on this topic was from Guy Ellis,
From: Guy Ellis <guy@traverse.com.au>
To: linux-atm-general@lists.sourceforge.net
Subject: Re: [Linux-ATM-General] solos-pci.c: Fix me
Date: Tue, 22 Jul 2014 07:34:30 +1000
Hi Chas/Nick,
I think the FIXME is reminder to deal correctly with an unknown command.
At the moment an unknown command is treated as a PKT_COMMAND which is
incorrect.
I think the correct behaviour would be to ignore unknown commands and
just free the skb.
That said I doubt this condition ever occurs, which is probably why it
has been this way since day 1.
Nathan is on vacation at the moment, when he gets back in August I'll
ask him to tidy this up.
So perhaps, Guy could let us know if he had a chance for Nathan to
look at removing this FIXME.
On Wed, 03 Dec 2014 22:58:46 -0500
nick <xerofoify@gmail.com> wrote:
> Greetings Chas,
> I am wondering if there is any reason for the FIXME message in the below code. This is due to after reading the other parts of the function the code and logical seem similar and correct unless I am missing something about the hardware.
> Cheers Nick
> case PKT_COMMAND:
> default: /* FIXME: Not really, surely? */
> if (process_command(card, port, skb))
> break;
> spin_lock(&card->cli_queue_lock);
> if (skb_queue_len(&card->cli_queue[port]) > 10) {
> if (net_ratelimit())
> dev_warn(&card->dev->dev, "Dropping console response on port %d\n",
> port);
> dev_kfree_skb_any(skb);
> } else
> skb_queue_tail(&card->cli_queue[port], skb);
> spin_unlock(&card->cli_queue_lock);
> break;
> }
>
>
^ permalink raw reply
* Re: [patch iproute2 6/6] bridge/link: add learning_sync policy flag
From: Jamal Hadi Salim @ 2014-12-04 14:15 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <54806115.9080008@mojatatu.com>
On 12/04/14 08:26, Jamal Hadi Salim wrote:
> I actually dont think any of these patches needed an ack because they
> are off.
^^^ meant ok ;-> or obvious.
cheers,
jamal
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Andy Gospodarek @ 2014-12-04 14:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <1417683438-10935-2-git-send-email-jiri@resnulli.us>
On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> include/linux/if_link.h | 1 +
> ip/ipaddress.c | 8 ++++++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 4732063..a6e2594 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -145,6 +145,7 @@ enum {
> IFLA_CARRIER,
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> + IFLA_PHYS_SWITCH_ID,
Serious question for Stephen et al, once we take this to iproute2 are we
going to be able to change the name but the string diplayed if needed?
I had a patch that called this IFLA_PARENT_ID that I was using with the
older github tree used by Jiri and Scott before these were in net-next.
I wanted to submit that as a change to what became
82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
be accepted and the dust settled.
I like the parent/child/sibling nomenclature better for 4 reasons:
- Most did not seem to like the term 'offload' since that term would be
confusing with, GRO, GSO, etc.
- A *significant* use case for many of the high-end ASICs in datacenters
is routing.
- switchid does not make sense in the OVS/flow case because it is all
about flows, not switches or routers, and parent made sense there.
- I wanted to combine this for use with SR-IOV use case, so one can more
easily map PF->VF using this.
Can you give me a bit (a day) to clean-up that patch and submit an
alternative proposal to these?
> __IFLA_MAX
> };
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 4d99324..bd36a07 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
> b1, sizeof(b1)));
> }
>
> + if (tb[IFLA_PHYS_SWITCH_ID]) {
> + SPRINT_BUF(b1);
> + fprintf(fp, "switchid %s ",
> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
> + b1, sizeof(b1)));
> + }
> +
> if (tb[IFLA_OPERSTATE])
> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
>
> --
> 1.9.3
>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Roopa Prabhu @ 2014-12-04 14:22 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jamal Hadi Salim, Jiri Pirko, netdev, davem, nhorman, andy, tgraf,
dborkman, ogerlitz, jesse, pshelar, azhou, ben, stephen,
jeffrey.t.kirsher, vyasevic, xiyou.wangcong, john.r.fastabend,
edumazet, sfeldma, f.fainelli, linville, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, bcrl
In-Reply-To: <20141204135621.GQ27416@gospo.rtplab.test>
On 12/4/14, 5:56 AM, Andy Gospodarek wrote:
> On Thu, Dec 04, 2014 at 08:16:38AM -0500, Jamal Hadi Salim wrote:
>> General comment:
>> iproute2 patches need to be addressed to the maintainer
>> stephen@networkplumber.org
>> And are we mainstream enough now we can drop the 1000 people on the
>> To: list? I doubt most of these people are even following the discussion (I
>> planted an easter egg for Aviad and didnt see him
>> reacting) ;->
> I actually don't mind them coming here since it is a change to netlink.
> Thanks for sending them to netdev, Jiri.
I think jamal meant the people in the cc (not netdev).
I actually like the cc, but that probably cant last long because it is a
lot of people.
>
>> cheers,
>> jamal
>>
>> On 12/04/14 03:57, Jiri Pirko wrote:
>>> Jiri Pirko (1):
>>> iproute2: ipa: show switch id
>>>
>>> Scott Feldman (5):
>>> bridge/fdb: fix statistics output spacing
>>> bridge/fdb: add flag/indication for FDB entry synced from offload
>>> device
>>> bridge/link: add new offload hwmode swdev
>>> link: add missing IFLA_BRPORT_PROXYARP
>>> bridge/link: add learning_sync policy flag
>>>
>>> bridge/fdb.c | 4 +++-
>>> bridge/link.c | 17 +++++++++++++++--
>>> include/linux/if_bridge.h | 1 +
>>> include/linux/if_link.h | 3 +++
>>> include/linux/neighbour.h | 1 +
>>> ip/ipaddress.c | 8 ++++++++
>>> man/man8/bridge.8 | 19 ++++++++++++++-----
>>> 7 files changed, 45 insertions(+), 8 deletions(-)
>>>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Roopa Prabhu @ 2014-12-04 14:26 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
On 12/4/14, 12:57 AM, Jiri Pirko wrote:
> Jiri Pirko (1):
> iproute2: ipa: show switch id
>
> Scott Feldman (5):
> bridge/fdb: fix statistics output spacing
> bridge/fdb: add flag/indication for FDB entry synced from offload
> device
> bridge/link: add new offload hwmode swdev
Ack to most patches but nack on this one. The todo list still has a note
to revist the flag to indicate switchdev offloads.
Exposing this to userspace does not help that.
> link: add missing IFLA_BRPORT_PROXYARP
> bridge/link: add learning_sync policy flag
>
> bridge/fdb.c | 4 +++-
> bridge/link.c | 17 +++++++++++++++--
> include/linux/if_bridge.h | 1 +
> include/linux/if_link.h | 3 +++
> include/linux/neighbour.h | 1 +
> ip/ipaddress.c | 8 ++++++++
> man/man8/bridge.8 | 19 ++++++++++++++-----
> 7 files changed, 45 insertions(+), 8 deletions(-)
>
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Roopa Prabhu @ 2014-12-04 14:29 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, jhs,
sfeldma, f.fainelli, linville, jasowang, ebiederm,
nicolas.dichtel, ryazanov.s.a, buytenh, aviadr, nbd,
alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204142015.GR27416@gospo.rtplab.test>
On 12/4/14, 6:20 AM, Andy Gospodarek wrote:
> On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> include/linux/if_link.h | 1 +
>> ip/ipaddress.c | 8 ++++++++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
>> index 4732063..a6e2594 100644
>> --- a/include/linux/if_link.h
>> +++ b/include/linux/if_link.h
>> @@ -145,6 +145,7 @@ enum {
>> IFLA_CARRIER,
>> IFLA_PHYS_PORT_ID,
>> IFLA_CARRIER_CHANGES,
>> + IFLA_PHYS_SWITCH_ID,
> Serious question for Stephen et al, once we take this to iproute2 are we
> going to be able to change the name but the string diplayed if needed?
>
> I had a patch that called this IFLA_PARENT_ID that I was using with the
> older github tree used by Jiri and Scott before these were in net-next.
> I wanted to submit that as a change to what became
> 82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
> be accepted and the dust settled.
>
> I like the parent/child/sibling nomenclature better for 4 reasons:
>
> - Most did not seem to like the term 'offload' since that term would be
> confusing with, GRO, GSO, etc.
> - A *significant* use case for many of the high-end ASICs in datacenters
> is routing.
> - switchid does not make sense in the OVS/flow case because it is all
> about flows, not switches or routers, and parent made sense there.
> - I wanted to combine this for use with SR-IOV use case, so one can more
> easily map PF->VF using this.
ack.., I have voted for calling it a generic parent id in the past.
>
> Can you give me a bit (a day) to clean-up that patch and submit an
> alternative proposal to these?
>
>> __IFLA_MAX
>> };
>>
>> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
>> index 4d99324..bd36a07 100644
>> --- a/ip/ipaddress.c
>> +++ b/ip/ipaddress.c
>> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
>> b1, sizeof(b1)));
>> }
>>
>> + if (tb[IFLA_PHYS_SWITCH_ID]) {
>> + SPRINT_BUF(b1);
>> + fprintf(fp, "switchid %s ",
>> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
>> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
>> + b1, sizeof(b1)));
>> + }
>> +
>> if (tb[IFLA_OPERSTATE])
>> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
>>
>> --
>> 1.9.3
>>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Jamal Hadi Salim @ 2014-12-04 14:31 UTC (permalink / raw)
To: Roopa Prabhu, Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, nhorman, andy, tgraf, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <54806E1B.5010402@cumulusnetworks.com>
On 12/04/14 09:22, Roopa Prabhu wrote:
> On 12/4/14, 5:56 AM, Andy Gospodarek wrote:
> I think jamal meant the people in the cc (not netdev).
> I actually like the cc, but that probably cant last long because it is a
> lot of people.
There are 34 people on that list. I support copying all stake holders
but it is too large.
cheers,
jamal
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jiri Pirko @ 2014-12-04 14:33 UTC (permalink / raw)
To: Andy Gospodarek
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204142015.GR27416@gospo.rtplab.test>
Thu, Dec 04, 2014 at 03:20:15PM CET, gospo@cumulusnetworks.com wrote:
>On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> include/linux/if_link.h | 1 +
>> ip/ipaddress.c | 8 ++++++++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
>> index 4732063..a6e2594 100644
>> --- a/include/linux/if_link.h
>> +++ b/include/linux/if_link.h
>> @@ -145,6 +145,7 @@ enum {
>> IFLA_CARRIER,
>> IFLA_PHYS_PORT_ID,
>> IFLA_CARRIER_CHANGES,
>> + IFLA_PHYS_SWITCH_ID,
>
>Serious question for Stephen et al, once we take this to iproute2 are we
>going to be able to change the name but the string diplayed if needed?
>
>I had a patch that called this IFLA_PARENT_ID that I was using with the
>older github tree used by Jiri and Scott before these were in net-next.
>I wanted to submit that as a change to what became
>82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
>be accepted and the dust settled.
>
>I like the parent/child/sibling nomenclature better for 4 reasons:
>
>- Most did not seem to like the term 'offload' since that term would be
> confusing with, GRO, GSO, etc.
>- A *significant* use case for many of the high-end ASICs in datacenters
> is routing.
>- switchid does not make sense in the OVS/flow case because it is all
> about flows, not switches or routers, and parent made sense there.
well ovs is all about flows and has the "switch" word in the name. I
believe that people are talking about "switches" in case of these "flow
devices" as well. I see nothing wrong in that. I think that "switch"
became generic name for "packet forwarding machines".
"parent" is very generic and may mean 100 things...
>- I wanted to combine this for use with SR-IOV use case, so one can more
> easily map PF->VF using this.
Ugh, please don't mix this up with pf, vf. That is completely different
thing.
pf vf mapping is done in sysfs. In netlink, physportid is used for that
purpose. We can expose this phys port id for pf as well (as a different
attr) and we are done.
>
>Can you give me a bit (a day) to clean-up that patch and submit an
>alternative proposal to these?
>
>> __IFLA_MAX
>> };
>>
>> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
>> index 4d99324..bd36a07 100644
>> --- a/ip/ipaddress.c
>> +++ b/ip/ipaddress.c
>> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
>> b1, sizeof(b1)));
>> }
>>
>> + if (tb[IFLA_PHYS_SWITCH_ID]) {
>> + SPRINT_BUF(b1);
>> + fprintf(fp, "switchid %s ",
>> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
>> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
>> + b1, sizeof(b1)));
>> + }
>> +
>> if (tb[IFLA_OPERSTATE])
>> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
>>
>> --
>> 1.9.3
>>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Jiri Pirko @ 2014-12-04 14:34 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl, hemal
In-Reply-To: <54806F2A.2050109@cumulusnetworks.com>
Thu, Dec 04, 2014 at 03:26:50PM CET, roopa@cumulusnetworks.com wrote:
>On 12/4/14, 12:57 AM, Jiri Pirko wrote:
>>Jiri Pirko (1):
>> iproute2: ipa: show switch id
>>
>>Scott Feldman (5):
>> bridge/fdb: fix statistics output spacing
>> bridge/fdb: add flag/indication for FDB entry synced from offload
>> device
>> bridge/link: add new offload hwmode swdev
>Ack to most patches but nack on this one. The todo list still has a note to
>revist the flag to indicate switchdev offloads.
>Exposing this to userspace does not help that.
Hmm, note that this is already exposed to userspace, this patchset is
for iproute2 (userspace tool).
>
>> link: add missing IFLA_BRPORT_PROXYARP
>> bridge/link: add learning_sync policy flag
>>
>> bridge/fdb.c | 4 +++-
>> bridge/link.c | 17 +++++++++++++++--
>> include/linux/if_bridge.h | 1 +
>> include/linux/if_link.h | 3 +++
>> include/linux/neighbour.h | 1 +
>> ip/ipaddress.c | 8 ++++++++
>> man/man8/bridge.8 | 19 ++++++++++++++-----
>> 7 files changed, 45 insertions(+), 8 deletions(-)
>>
>
^ permalink raw reply
* Re: [patch iproute2 0/6] iproute2: add changes for switchdev
From: Roopa Prabhu @ 2014-12-04 14:45 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl, hemal
In-Reply-To: <20141204143400.GC1861@nanopsycho.orion>
On 12/4/14, 6:34 AM, Jiri Pirko wrote:
> Thu, Dec 04, 2014 at 03:26:50PM CET, roopa@cumulusnetworks.com wrote:
>> On 12/4/14, 12:57 AM, Jiri Pirko wrote:
>>> Jiri Pirko (1):
>>> iproute2: ipa: show switch id
>>>
>>> Scott Feldman (5):
>>> bridge/fdb: fix statistics output spacing
>>> bridge/fdb: add flag/indication for FDB entry synced from offload
>>> device
>>> bridge/link: add new offload hwmode swdev
>> Ack to most patches but nack on this one. The todo list still has a note to
>> revist the flag to indicate switchdev offloads.
>> Exposing this to userspace does not help that.
> Hmm, note that this is already exposed to userspace, this patchset is
> for iproute2 (userspace tool).
hmmm, all feedback on the switchdev patches seemed to indicate we can
change this later.
I don't see swdev mode being used in the kernel anywhere today.
I will send a patch to remove it. Its still in net-next and so can be
changed ?.
I was going to resend my patch to introduce a common offload flag for
all link objects.
It would be nice if all of them had a consistent flag to indicate hw
offload and iproute2 could display the same flag for all.
Including bonds and vxlan's.
>
>>> link: add missing IFLA_BRPORT_PROXYARP
>>> bridge/link: add learning_sync policy flag
>>>
>>> bridge/fdb.c | 4 +++-
>>> bridge/link.c | 17 +++++++++++++++--
>>> include/linux/if_bridge.h | 1 +
>>> include/linux/if_link.h | 3 +++
>>> include/linux/neighbour.h | 1 +
>>> ip/ipaddress.c | 8 ++++++++
>>> man/man8/bridge.8 | 19 ++++++++++++++-----
>>> 7 files changed, 45 insertions(+), 8 deletions(-)
>>>
^ permalink raw reply
* Re: [PATCH v2] drivers: net : cpsw: Update Kconfig for CPSW
From: Felipe Balbi @ 2014-12-04 14:48 UTC (permalink / raw)
To: Lokesh Vutla
Cc: netdev, davem, mugunthanvnm, linux-omap, grygorii.strashko, balbi,
nsekhar, t-kristo
In-Reply-To: <1417668869-25616-1-git-send-email-lokeshvutla@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]
On Thu, Dec 04, 2014 at 10:24:29AM +0530, Lokesh Vutla wrote:
> CPSW is present in AM33xx, AM43xx, DRA7xx.
> Updating the Kconfig to depend on ARCH_OMAP2PLUS instead of listing
> all SoC's.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/net/ethernet/ti/Kconfig | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 5d8cb79..7051255 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -5,7 +5,7 @@
> config NET_VENDOR_TI
> bool "Texas Instruments (TI) devices"
> default y
> - depends on PCI || EISA || AR7 || (ARM && (ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX || ARCH_KEYSTONE))
> + depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y
> and read the Ethernet-HOWTO, available from
> @@ -32,7 +32,7 @@ config TI_DAVINCI_EMAC
>
> config TI_DAVINCI_MDIO
> tristate "TI DaVinci MDIO Support"
> - depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX || ARCH_KEYSTONE )
> + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
> select PHYLIB
> ---help---
> This driver supports TI's DaVinci MDIO module.
> @@ -42,7 +42,7 @@ config TI_DAVINCI_MDIO
>
> config TI_DAVINCI_CPDMA
> tristate "TI DaVinci CPDMA Support"
> - depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX )
> + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
> ---help---
> This driver supports TI's DaVinci CPDMA dma engine.
>
> @@ -58,7 +58,7 @@ config TI_CPSW_PHY_SEL
>
> config TI_CPSW
> tristate "TI CPSW Switch Support"
> - depends on ARM && (ARCH_DAVINCI || SOC_AM33XX)
> + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
> select TI_DAVINCI_CPDMA
> select TI_DAVINCI_MDIO
> select TI_CPSW_PHY_SEL
> --
> 1.9.1
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Andy Gospodarek @ 2014-12-04 14:57 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204143306.GB1861@nanopsycho.orion>
On Thu, Dec 04, 2014 at 03:33:06PM +0100, Jiri Pirko wrote:
> Thu, Dec 04, 2014 at 03:20:15PM CET, gospo@cumulusnetworks.com wrote:
> >On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
> >> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >> ---
> >> include/linux/if_link.h | 1 +
> >> ip/ipaddress.c | 8 ++++++++
> >> 2 files changed, 9 insertions(+)
> >>
> >> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> >> index 4732063..a6e2594 100644
> >> --- a/include/linux/if_link.h
> >> +++ b/include/linux/if_link.h
> >> @@ -145,6 +145,7 @@ enum {
> >> IFLA_CARRIER,
> >> IFLA_PHYS_PORT_ID,
> >> IFLA_CARRIER_CHANGES,
> >> + IFLA_PHYS_SWITCH_ID,
> >
> >Serious question for Stephen et al, once we take this to iproute2 are we
> >going to be able to change the name but the string diplayed if needed?
> >
> >I had a patch that called this IFLA_PARENT_ID that I was using with the
> >older github tree used by Jiri and Scott before these were in net-next.
> >I wanted to submit that as a change to what became
> >82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
> >be accepted and the dust settled.
> >
> >I like the parent/child/sibling nomenclature better for 4 reasons:
> >
> >- Most did not seem to like the term 'offload' since that term would be
> > confusing with, GRO, GSO, etc.
> >- A *significant* use case for many of the high-end ASICs in datacenters
> > is routing.
> >- switchid does not make sense in the OVS/flow case because it is all
> > about flows, not switches or routers, and parent made sense there.
>
> well ovs is all about flows and has the "switch" word in the name. I
> believe that people are talking about "switches" in case of these "flow
> devices" as well. I see nothing wrong in that. I think that "switch"
> became generic name for "packet forwarding machines".
Just because one chose to use it that way does not mean I agree with it
and that we should copy their bad decision. :-)
> "parent" is very generic and may mean 100 things...
But in this case, it means 1 thing. The netdev you are using is
connected to another device that controls it rather than being just a
NIC.
>
>
> >- I wanted to combine this for use with SR-IOV use case, so one can more
> > easily map PF->VF using this.
>
> Ugh, please don't mix this up with pf, vf. That is completely different
> thing.
>
> pf vf mapping is done in sysfs. In netlink, physportid is used for that
> purpose. We can expose this phys port id for pf as well (as a different
> attr) and we are done.
I know that attribute is there, but I find it more valuable for
solutions like nPAR than for PF/VF use-case. Parent/child relationship
makes more sense to me since for forwarding will be controlled by the
embedded switch on those devices. (Notice I specifically chose not to
use 'master' since that is already overloaded by bridge, bonding,
teaming, etc.)
>
> >
> >Can you give me a bit (a day) to clean-up that patch and submit an
> >alternative proposal to these?
> >
> >> __IFLA_MAX
> >> };
> >>
> >> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> >> index 4d99324..bd36a07 100644
> >> --- a/ip/ipaddress.c
> >> +++ b/ip/ipaddress.c
> >> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
> >> b1, sizeof(b1)));
> >> }
> >>
> >> + if (tb[IFLA_PHYS_SWITCH_ID]) {
> >> + SPRINT_BUF(b1);
> >> + fprintf(fp, "switchid %s ",
> >> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
> >> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
> >> + b1, sizeof(b1)));
> >> + }
> >> +
> >> if (tb[IFLA_OPERSTATE])
> >> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
> >>
> >> --
> >> 1.9.3
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jiri Pirko @ 2014-12-04 15:12 UTC (permalink / raw)
To: Andy Gospodarek
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204145743.GS27416@gospo.rtplab.test>
Thu, Dec 04, 2014 at 03:57:43PM CET, gospo@cumulusnetworks.com wrote:
>On Thu, Dec 04, 2014 at 03:33:06PM +0100, Jiri Pirko wrote:
>> Thu, Dec 04, 2014 at 03:20:15PM CET, gospo@cumulusnetworks.com wrote:
>> >On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
>> >> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> >> ---
>> >> include/linux/if_link.h | 1 +
>> >> ip/ipaddress.c | 8 ++++++++
>> >> 2 files changed, 9 insertions(+)
>> >>
>> >> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
>> >> index 4732063..a6e2594 100644
>> >> --- a/include/linux/if_link.h
>> >> +++ b/include/linux/if_link.h
>> >> @@ -145,6 +145,7 @@ enum {
>> >> IFLA_CARRIER,
>> >> IFLA_PHYS_PORT_ID,
>> >> IFLA_CARRIER_CHANGES,
>> >> + IFLA_PHYS_SWITCH_ID,
>> >
>> >Serious question for Stephen et al, once we take this to iproute2 are we
>> >going to be able to change the name but the string diplayed if needed?
>> >
>> >I had a patch that called this IFLA_PARENT_ID that I was using with the
>> >older github tree used by Jiri and Scott before these were in net-next.
>> >I wanted to submit that as a change to what became
>> >82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
>> >be accepted and the dust settled.
>> >
>> >I like the parent/child/sibling nomenclature better for 4 reasons:
>> >
>> >- Most did not seem to like the term 'offload' since that term would be
>> > confusing with, GRO, GSO, etc.
>> >- A *significant* use case for many of the high-end ASICs in datacenters
>> > is routing.
>> >- switchid does not make sense in the OVS/flow case because it is all
>> > about flows, not switches or routers, and parent made sense there.
>>
>> well ovs is all about flows and has the "switch" word in the name. I
>> believe that people are talking about "switches" in case of these "flow
>> devices" as well. I see nothing wrong in that. I think that "switch"
>> became generic name for "packet forwarding machines".
>
>Just because one chose to use it that way does not mean I agree with it
>and that we should copy their bad decision. :-)
>
>> "parent" is very generic and may mean 100 things...
>
>But in this case, it means 1 thing. The netdev you are using is
>connected to another device that controls it rather than being just a
>NIC.
when we discussed linkage now called upper/lower devices, there was a
proposal to use "parent" as well. And then it ment only 1 thing as well.
Why for example pf is not parent of vf? Using "parent" word here and
assume that it just makes sense for this case is IMHO wrong. Too
generic. "switch_parent" - that I am okay with.
>
>>
>>
>> >- I wanted to combine this for use with SR-IOV use case, so one can more
>> > easily map PF->VF using this.
>>
>> Ugh, please don't mix this up with pf, vf. That is completely different
>> thing.
>>
>> pf vf mapping is done in sysfs. In netlink, physportid is used for that
>> purpose. We can expose this phys port id for pf as well (as a different
>> attr) and we are done.
>
>I know that attribute is there, but I find it more valuable for
>solutions like nPAR than for PF/VF use-case.
Why it is not good enough for pf/vf? There are SR-IOV drivers using
this:
$ git grep ndo_get_phys_port_id
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: .ndo_get_phys_port_id = bnx2x_get_phys_port_id,
drivers/net/ethernet/intel/i40e/i40e_main.c: .ndo_get_phys_port_id = i40e_get_phys_port_id,
drivers/net/ethernet/mellanox/mlx4/en_netdev.c: .ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
drivers/net/ethernet/mellanox/mlx4/en_netdev.c: .ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c: .ndo_get_phys_port_id = qlcnic_get_phys_port_id,
>Parent/child relationship
>makes more sense to me since for forwarding will be controlled by the
>embedded switch on those devices. (Notice I specifically chose not to
>use 'master' since that is already overloaded by bridge, bonding,
>teaming, etc.)
But is that embedded switch the same thing as PF? I doubt that. Let the
aspect of PF/VF aside and look at it as on ordinary switch. The eswitch
driver needs te be implemented and add netdevs for internal ports (they
do not exist now).
You have to look at PF/VF and eSwitch as on separate things.
>
>>
>> >
>> >Can you give me a bit (a day) to clean-up that patch and submit an
>> >alternative proposal to these?
>> >
>> >> __IFLA_MAX
>> >> };
>> >>
>> >> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
>> >> index 4d99324..bd36a07 100644
>> >> --- a/ip/ipaddress.c
>> >> +++ b/ip/ipaddress.c
>> >> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
>> >> b1, sizeof(b1)));
>> >> }
>> >>
>> >> + if (tb[IFLA_PHYS_SWITCH_ID]) {
>> >> + SPRINT_BUF(b1);
>> >> + fprintf(fp, "switchid %s ",
>> >> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
>> >> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
>> >> + b1, sizeof(b1)));
>> >> + }
>> >> +
>> >> if (tb[IFLA_OPERSTATE])
>> >> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
>> >>
>> >> --
>> >> 1.9.3
>> >>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jiri Pirko @ 2014-12-04 15:15 UTC (permalink / raw)
To: Andy Gospodarek
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204145743.GS27416@gospo.rtplab.test>
Thu, Dec 04, 2014 at 03:57:43PM CET, gospo@cumulusnetworks.com wrote:
>On Thu, Dec 04, 2014 at 03:33:06PM +0100, Jiri Pirko wrote:
>> Thu, Dec 04, 2014 at 03:20:15PM CET, gospo@cumulusnetworks.com wrote:
>> >On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
>> >> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> >> ---
>> >> include/linux/if_link.h | 1 +
>> >> ip/ipaddress.c | 8 ++++++++
>> >> 2 files changed, 9 insertions(+)
>> >>
>> >> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
>> >> index 4732063..a6e2594 100644
>> >> --- a/include/linux/if_link.h
>> >> +++ b/include/linux/if_link.h
>> >> @@ -145,6 +145,7 @@ enum {
>> >> IFLA_CARRIER,
>> >> IFLA_PHYS_PORT_ID,
>> >> IFLA_CARRIER_CHANGES,
>> >> + IFLA_PHYS_SWITCH_ID,
>> >
>> >Serious question for Stephen et al, once we take this to iproute2 are we
>> >going to be able to change the name but the string diplayed if needed?
>> >
>> >I had a patch that called this IFLA_PARENT_ID that I was using with the
>> >older github tree used by Jiri and Scott before these were in net-next.
>> >I wanted to submit that as a change to what became
>> >82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
>> >be accepted and the dust settled.
>> >
>> >I like the parent/child/sibling nomenclature better for 4 reasons:
>> >
>> >- Most did not seem to like the term 'offload' since that term would be
>> > confusing with, GRO, GSO, etc.
>> >- A *significant* use case for many of the high-end ASICs in datacenters
>> > is routing.
>> >- switchid does not make sense in the OVS/flow case because it is all
>> > about flows, not switches or routers, and parent made sense there.
>>
>> well ovs is all about flows and has the "switch" word in the name. I
>> believe that people are talking about "switches" in case of these "flow
>> devices" as well. I see nothing wrong in that. I think that "switch"
>> became generic name for "packet forwarding machines".
>
>Just because one chose to use it that way does not mean I agree with it
>and that we should copy their bad decision. :-)
>
>> "parent" is very generic and may mean 100 things...
>
>But in this case, it means 1 thing. The netdev you are using is
>connected to another device that controls it rather than being just a
>NIC.
>
>>
>>
>> >- I wanted to combine this for use with SR-IOV use case, so one can more
>> > easily map PF->VF using this.
>>
>> Ugh, please don't mix this up with pf, vf. That is completely different
>> thing.
>>
>> pf vf mapping is done in sysfs. In netlink, physportid is used for that
>> purpose. We can expose this phys port id for pf as well (as a different
>> attr) and we are done.
>
>I know that attribute is there, but I find it more valuable for
>solutions like nPAR than for PF/VF use-case. Parent/child relationship
>makes more sense to me since for forwarding will be controlled by the
>embedded switch on those devices. (Notice I specifically chose not to
see, "embedded switch", not "embedded parent" or "embedded offload". And
yes, the "embedded switch" also may (and some of them do today) work
with flows.
>use 'master' since that is already overloaded by bridge, bonding,
>teaming, etc.)
>
>>
>> >
>> >Can you give me a bit (a day) to clean-up that patch and submit an
>> >alternative proposal to these?
>> >
>> >> __IFLA_MAX
>> >> };
>> >>
>> >> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
>> >> index 4d99324..bd36a07 100644
>> >> --- a/ip/ipaddress.c
>> >> +++ b/ip/ipaddress.c
>> >> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
>> >> b1, sizeof(b1)));
>> >> }
>> >>
>> >> + if (tb[IFLA_PHYS_SWITCH_ID]) {
>> >> + SPRINT_BUF(b1);
>> >> + fprintf(fp, "switchid %s ",
>> >> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
>> >> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
>> >> + b1, sizeof(b1)));
>> >> + }
>> >> +
>> >> if (tb[IFLA_OPERSTATE])
>> >> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
>> >>
>> >> --
>> >> 1.9.3
>> >>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Thomas Graf @ 2014-12-04 15:26 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, David S. Miller, Theodore Ts'o, netdev,
Linux Kernel Mailing List
In-Reply-To: <20141204081147.GA19030@gondor.apana.org.au>
On 12/04/14 at 04:11pm, Herbert Xu wrote:
> Hi:
>
> While working on rhashtable it came to me that this whole concept
> of arch_fast_hash is flawed. CRCs are linear functions so it's
> fairly easy for an attacker to identify collisions or at least
> eliminate a large amount of search space (e.g., controlling the
> last bit of the hash result is almost trivial, even when you add
> a random seed).
>
> So what exactly are we going to use arch_fast_hash for? Presumably
> it's places where security is never goint to be an issue, right?
>
> Even if security wasn't an issue, straight CRC32 has really poor
> lower-order bit distribution, which makes it a terrible choice for
> a hash table that simply uses the lower-order bits.
As Daniel pointed out, this work originated for the OVS edge use
case where security is of less concern and the rehashing is
sufficient. Identifying collisions is less of interest as the user
space fall back provides a greater surface for an attack.
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Andy Gospodarek @ 2014-12-04 15:28 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hemal
In-Reply-To: <20141204151512.GE1861@nanopsycho.orion>
On Thu, Dec 04, 2014 at 04:15:12PM +0100, Jiri Pirko wrote:
> Thu, Dec 04, 2014 at 03:57:43PM CET, gospo@cumulusnetworks.com wrote:
> >On Thu, Dec 04, 2014 at 03:33:06PM +0100, Jiri Pirko wrote:
> >> Thu, Dec 04, 2014 at 03:20:15PM CET, gospo@cumulusnetworks.com wrote:
> >> >On Thu, Dec 04, 2014 at 09:57:13AM +0100, Jiri Pirko wrote:
> >> >> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >> >> ---
> >> >> include/linux/if_link.h | 1 +
> >> >> ip/ipaddress.c | 8 ++++++++
> >> >> 2 files changed, 9 insertions(+)
> >> >>
> >> >> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> >> >> index 4732063..a6e2594 100644
> >> >> --- a/include/linux/if_link.h
> >> >> +++ b/include/linux/if_link.h
> >> >> @@ -145,6 +145,7 @@ enum {
> >> >> IFLA_CARRIER,
> >> >> IFLA_PHYS_PORT_ID,
> >> >> IFLA_CARRIER_CHANGES,
> >> >> + IFLA_PHYS_SWITCH_ID,
> >> >
> >> >Serious question for Stephen et al, once we take this to iproute2 are we
> >> >going to be able to change the name but the string diplayed if needed?
> >> >
> >> >I had a patch that called this IFLA_PARENT_ID that I was using with the
> >> >older github tree used by Jiri and Scott before these were in net-next.
> >> >I wanted to submit that as a change to what became
> >> >82f2841291cfaf4d225aa1766424280254d3e3b2, but was waiting for things to
> >> >be accepted and the dust settled.
> >> >
> >> >I like the parent/child/sibling nomenclature better for 4 reasons:
> >> >
> >> >- Most did not seem to like the term 'offload' since that term would be
> >> > confusing with, GRO, GSO, etc.
> >> >- A *significant* use case for many of the high-end ASICs in datacenters
> >> > is routing.
> >> >- switchid does not make sense in the OVS/flow case because it is all
> >> > about flows, not switches or routers, and parent made sense there.
> >>
> >> well ovs is all about flows and has the "switch" word in the name. I
> >> believe that people are talking about "switches" in case of these "flow
> >> devices" as well. I see nothing wrong in that. I think that "switch"
> >> became generic name for "packet forwarding machines".
> >
> >Just because one chose to use it that way does not mean I agree with it
> >and that we should copy their bad decision. :-)
> >
> >> "parent" is very generic and may mean 100 things...
> >
> >But in this case, it means 1 thing. The netdev you are using is
> >connected to another device that controls it rather than being just a
> >NIC.
> >
> >>
> >>
> >> >- I wanted to combine this for use with SR-IOV use case, so one can more
> >> > easily map PF->VF using this.
> >>
> >> Ugh, please don't mix this up with pf, vf. That is completely different
> >> thing.
> >>
> >> pf vf mapping is done in sysfs. In netlink, physportid is used for that
> >> purpose. We can expose this phys port id for pf as well (as a different
> >> attr) and we are done.
> >
> >I know that attribute is there, but I find it more valuable for
> >solutions like nPAR than for PF/VF use-case. Parent/child relationship
> >makes more sense to me since for forwarding will be controlled by the
> >embedded switch on those devices. (Notice I specifically chose not to
>
> see, "embedded switch", not "embedded parent" or "embedded offload". And
> yes, the "embedded switch" also may (and some of them do today) work
> with flows.
It's fine to exclude the PF/VF part for now since you seem disagree with
that as a valid reason. The other 3 reasons are in my mind, so that was
why I asked to Stephen would mind waiting for me to post my set. I'm
not asking for you to do anything here but to be patient and let me get
the set out.
>
>
> >use 'master' since that is already overloaded by bridge, bonding,
> >teaming, etc.)
> >
> >>
> >> >
> >> >Can you give me a bit (a day) to clean-up that patch and submit an
> >> >alternative proposal to these?
> >> >
> >> >> __IFLA_MAX
> >> >> };
> >> >>
> >> >> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> >> >> index 4d99324..bd36a07 100644
> >> >> --- a/ip/ipaddress.c
> >> >> +++ b/ip/ipaddress.c
> >> >> @@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
> >> >> b1, sizeof(b1)));
> >> >> }
> >> >>
> >> >> + if (tb[IFLA_PHYS_SWITCH_ID]) {
> >> >> + SPRINT_BUF(b1);
> >> >> + fprintf(fp, "switchid %s ",
> >> >> + hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
> >> >> + RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
> >> >> + b1, sizeof(b1)));
> >> >> + }
> >> >> +
> >> >> if (tb[IFLA_OPERSTATE])
> >> >> print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
> >> >>
> >> >> --
> >> >> 1.9.3
> >> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Herbert Xu @ 2014-12-04 15:29 UTC (permalink / raw)
To: Thomas Graf
Cc: Daniel Borkmann, David S. Miller, Theodore Ts'o, netdev,
Linux Kernel Mailing List
In-Reply-To: <20141204152637.GA32140@casper.infradead.org>
On Thu, Dec 04, 2014 at 03:26:37PM +0000, Thomas Graf wrote:
>
> As Daniel pointed out, this work originated for the OVS edge use
> case where security is of less concern and the rehashing is
> sufficient. Identifying collisions is less of interest as the user
> space fall back provides a greater surface for an attack.
Well in that case the current setup I think is very misleading.
It's inviting unsuspecting kernel developers to use it as a hash
function for general hash tables, which AFAICS is something that
it fails at miserably.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Thomas Graf @ 2014-12-04 15:37 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, bcrl, hema
In-Reply-To: <20141204145743.GS27416@gospo.rtplab.test>
On 12/04/14 at 09:57am, Andy Gospodarek wrote:
> I know that attribute is there, but I find it more valuable for
> solutions like nPAR than for PF/VF use-case. Parent/child relationship
> makes more sense to me since for forwarding will be controlled by the
> embedded switch on those devices. (Notice I specifically chose not to
> use 'master' since that is already overloaded by bridge, bonding,
> teaming, etc.)
So that would make it link, master, and parent. Not sure we can make
it any more confusing ;-)
TBH, I'm really struggling on how to best name this. Trying to reach
for 100% correctness leads to generic, amgbigous names.
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Thomas Graf @ 2014-12-04 15:39 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, David S. Miller, Theodore Ts'o, netdev,
Linux Kernel Mailing List
In-Reply-To: <20141204152929.GA22075@gondor.apana.org.au>
On 12/04/14 at 11:29pm, Herbert Xu wrote:
> On Thu, Dec 04, 2014 at 03:26:37PM +0000, Thomas Graf wrote:
> >
> > As Daniel pointed out, this work originated for the OVS edge use
> > case where security is of less concern and the rehashing is
> > sufficient. Identifying collisions is less of interest as the user
> > space fall back provides a greater surface for an attack.
>
> Well in that case the current setup I think is very misleading.
> It's inviting unsuspecting kernel developers to use it as a hash
> function for general hash tables, which AFAICS is something that
> it fails at miserably.
Well, it's called fast hash and not secure hash ;-) but a clear hint
definitely wouldn't hurt.
I wasn't aware of the distribution weakness of the lower bits. Do
you have a reference to more information?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox