On Wed, Apr 18, 2018 at 09:26:34AM -0700, Jakub Kicinski wrote:
> On Wed, 18 Apr 2018 11:15:29 -0400, Andy Gospodarek wrote:
> > > A similar issue exists on multi-host for PFs, right? If one of the
> > > hosts is down do we still show their PF repr? IMHO yes.
> >
> > I would agree with that as
Miller ; Singhai, Anjali
> ; Michael Chan ;
> Simon Horman ; John Fastabend
> ; Saeed Mahameed ;
> Jiri Pirko ; Rony Efraim ; Linux
> Netdev List
> Subject: Re: SRIOV switchdev mode BoF minutes
>
> On Tue, Apr 17, 2018 at 04:19:15PM -0700, Jakub Kicinski wrote:
> > On
On Wed, 18 Apr 2018 11:15:29 -0400, Andy Gospodarek wrote:
> > A similar issue exists on multi-host for PFs, right? If one of the
> > hosts is down do we still show their PF repr? IMHO yes.
>
> I would agree with that as well. With today's model the VF reps are
> created once a PF is put into
On Tue, Apr 17, 2018 at 04:19:15PM -0700, Jakub Kicinski wrote:
> On Tue, 17 Apr 2018 10:47:00 -0400, Andy Gospodarek wrote:
> > There is also a school of thought that the VF reps could be
> > pre-allocated on the SmartNIC so that any application processing that
> > traffic would sit idle when no t
On Tue, 17 Apr 2018 10:47:00 -0400, Andy Gospodarek wrote:
> There is also a school of thought that the VF reps could be
> pre-allocated on the SmartNIC so that any application processing that
> traffic would sit idle when no traffic arrives on the rep, but could
> process frames that do arrive whe
On Tue, Apr 17, 2018 at 09:46:38AM -0700, Samudrala, Sridhar wrote:
> On 4/17/2018 7:47 AM, Andy Gospodarek wrote:
> > On Tue, Apr 17, 2018 at 04:58:05PM +0300, Or Gerlitz wrote:
> > > On Tue, Apr 17, 2018 at 4:30 PM, Andy Gospodarek
> > > wrote:
> > > > On Mon, Apr 16, 2018 at 07:08:39PM -0700, S
On 4/17/2018 7:47 AM, Andy Gospodarek wrote:
On Tue, Apr 17, 2018 at 04:58:05PM +0300, Or Gerlitz wrote:
On Tue, Apr 17, 2018 at 4:30 PM, Andy Gospodarek
wrote:
On Mon, Apr 16, 2018 at 07:08:39PM -0700, Samudrala, Sridhar wrote:
On 4/16/2018 5:39 AM, Andy Gospodarek wrote:
On Sun, Apr 15, 20
On Tue, Apr 17, 2018 at 04:58:05PM +0300, Or Gerlitz wrote:
> On Tue, Apr 17, 2018 at 4:30 PM, Andy Gospodarek
> wrote:
> > On Mon, Apr 16, 2018 at 07:08:39PM -0700, Samudrala, Sridhar wrote:
> >>
> >> On 4/16/2018 5:39 AM, Andy Gospodarek wrote:
> >> > On Sun, Apr 15, 2018 at 09:01:16AM +0300, Or
On Tue, Apr 17, 2018 at 4:30 PM, Andy Gospodarek
wrote:
> On Mon, Apr 16, 2018 at 07:08:39PM -0700, Samudrala, Sridhar wrote:
>>
>> On 4/16/2018 5:39 AM, Andy Gospodarek wrote:
>> > On Sun, Apr 15, 2018 at 09:01:16AM +0300, Or Gerlitz wrote:
>> > > On Sat, Apr 14, 2018 at 2:03 AM, Samudrala, Sridh
On Mon, Apr 16, 2018 at 07:08:39PM -0700, Samudrala, Sridhar wrote:
>
> On 4/16/2018 5:39 AM, Andy Gospodarek wrote:
> > On Sun, Apr 15, 2018 at 09:01:16AM +0300, Or Gerlitz wrote:
> > > On Sat, Apr 14, 2018 at 2:03 AM, Samudrala, Sridhar
> > > wrote:
> > >
> > > > I meant between PFs on 2 compu
On 4/16/2018 5:39 AM, Andy Gospodarek wrote:
On Sun, Apr 15, 2018 at 09:01:16AM +0300, Or Gerlitz wrote:
On Sat, Apr 14, 2018 at 2:03 AM, Samudrala, Sridhar
wrote:
I meant between PFs on 2 compute nodes.
If the PF serves as uplink rep, it functions as a switch port -- applications
don't ru
On Sun, Apr 15, 2018 at 09:01:16AM +0300, Or Gerlitz wrote:
> On Sat, Apr 14, 2018 at 2:03 AM, Samudrala, Sridhar
> wrote:
>
> > I meant between PFs on 2 compute nodes.
>
> If the PF serves as uplink rep, it functions as a switch port -- applications
> don't run on switch ports. One way to get
On Sat, Apr 14, 2018 at 2:03 AM, Samudrala, Sridhar
wrote:
> I meant between PFs on 2 compute nodes.
If the PF serves as uplink rep, it functions as a switch port -- applications
don't run on switch ports. One way to get apps to run on the host in switchdev
mode is probe one of the VFs there.
On 4/13/2018 1:16 PM, Or Gerlitz wrote:
On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar
wrote:
On 4/13/2018 1:57 AM, Or Gerlitz wrote:
in overlay networks scheme, the uplink rep has the VTEP ip and is not connected
to the bridge, e.g you use ovs you have vf reps and vxlan ports connecte
On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar
wrote:
> On 4/13/2018 1:57 AM, Or Gerlitz wrote:
>>> in overlay networks scheme, the uplink rep has the VTEP ip and is not
>>> connected
>>> to the bridge, e.g you use ovs you have vf reps and vxlan ports connected
>>> to ovs and the ip stack
On 4/13/2018 1:57 AM, Or Gerlitz wrote:
On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
wrote:
On 4/12/2018 1:20 PM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrot
On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote:
> On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
> wrote:
>> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>>
>>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>>> wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>
> Hi
On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
wrote:
> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>
>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>> wrote:
>>>
>>> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switch
On 4/12/2018 1:20 PM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switchdev mode, we came into a
consensus among the developers from four different HW vendors (CC
audi
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>
>> Hi Dave and all,
>>
>> During and after the BoF on SRIOV switchdev mode, we came into a
>> consensus among the developers from four different HW vendors (CC
>> audience) that a correct thin
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switchdev mode, we came into a
consensus among the developers from four different HW vendors (CC
audience) that a correct thing to do would be to disallow any new
extensions to the legacy mode.
The idea
On Thu, Nov 16, 2017 at 9:41 AM, Or Gerlitz wrote:
> On Wed, Nov 15, 2017 at 1:05 AM, Alexander Duyck
> wrote:
>> On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz wrote:
>
>>> all dealing with the sriov e-switch as a HW switch which should
>>> be programmed
>>> by the host stack according to well kno
On Wed, Nov 15, 2017 at 1:05 AM, Alexander Duyck
wrote:
> On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz wrote:
>> all dealing with the sriov e-switch as a HW switch which should
>> be programmed
>> by the host stack according to well known industry models that apply
>> on physical switches, e.g
>>
On Tue, Nov 14, 2017 at 8:02 PM, Jakub Kicinski
wrote:
> On Tue, 14 Nov 2017 19:04:36 -0800, Alexander Duyck wrote:
>> On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
>> wrote:
>> > On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
>> >> >> We basically need to do some feasability resear
On Tue, 14 Nov 2017 19:04:36 -0800, Alexander Duyck wrote:
> On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
> wrote:
> > On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
> >> >> We basically need to do some feasability research to see if we can
> >> >> actually meet all the requiremen
On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski
wrote:
> On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
>> >> We basically need to do some feasability research to see if we can
>> >> actually meet all the requirements for switchdev on i40e. We have been
>> >> getting mixed messages whe
On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote:
> >> We basically need to do some feasability research to see if we can
> >> actually meet all the requirements for switchdev on i40e. We have been
> >> getting mixed messages where we are given a great many "yes, but" type
> >> answers. Fo
On Tue, 14 Nov 2017 12:00:32 -0800, Alexander Duyck wrote:
> On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
> > On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck wrote:
> >> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
> > Lets focus on this point for a moment before discussing the ot
On Tue, Nov 14, 2017 at 1:50 PM, Or Gerlitz wrote:
> On Tue, Nov 14, 2017 at 10:00 PM, Alexander Duyck
> wrote:
>> On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
>>> On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
>>> wrote:
On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
> O
On Tue, Nov 14, 2017 at 10:00 PM, Alexander Duyck
wrote:
> On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
>> On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
>> wrote:
>>> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
>>
The
On Tue, Nov 14, 2017 at 8:44 AM, Or Gerlitz wrote:
> On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
> wrote:
>> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
>>> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
>
>>> The what we call slow path requirements are the following:
>>>
>>> 1.
On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
wrote:
> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
>> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
>> The what we call slow path requirements are the following:
>>
>> 1. xmit on VF rep always turns to a receive on the VF, regardless
On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz wrote:
> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
> wrote:
>> On Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz wrote:
>>> Hi Dave and all,
>>>
>>> During and after the BoF on SRIOV switchdev mode, we came into a
>>> consensus among the developers
On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck
wrote:
> On Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz wrote:
>> Hi Dave and all,
>>
>> During and after the BoF on SRIOV switchdev mode, we came into a
>> consensus among the developers from four different HW vendors (CC
>> audience) that a correc
On Sun, Nov 12, 2017 at 11:49 AM, Or Gerlitz wrote:
> Hi Dave and all,
>
> During and after the BoF on SRIOV switchdev mode, we came into a
> consensus among the developers from four different HW vendors (CC
> audience) that a correct thing to do would be to disallow any new
> extensions to the le
Hi Dave and all,
During and after the BoF on SRIOV switchdev mode, we came into a
consensus among the developers from four different HW vendors (CC
audience) that a correct thing to do would be to disallow any new
extensions to the legacy mode.
The idea is to put focus on the new mode and not add
36 matches
Mail list logo
