netdev - RE: [Intel-wired-lan] [PATCH net-next v2 05/13] ice: Fix RDMA latency issue by allowing write-combining

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Jan 2023 23:34:50 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "Lobakin, Alexandr" <alexandr.lobakin@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "Dave.Ertman@...el.com" <Dave.Ertman@...el.com>,
        "Saleem, Shiraz" <shiraz.saleem@...el.com>
CC:     Intel Wired LAN <intel-wired-lan@...ts.osuosl.org>,
        "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [Intel-wired-lan] [PATCH net-next v2 05/13] ice: Fix RDMA latency
 issue by allowing write-combining



> -----Original Message-----
> From: Lobakin, Alexandr <alexandr.lobakin@...el.com>
> Sent: Monday, January 30, 2023 2:03 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Intel Wired LAN <intel-wired-lan@...ts.osuosl.org>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; Linga, Pavan Kumar
> <pavan.kumar.linga@...el.com>; netdev@...r.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH net-next v2 05/13] ice: Fix RDMA latency
> issue by allowing write-combining
> 
> From: Jacob Keller <jacob.e.keller@...el.com>
> Date: Wed, 18 Jan 2023 17:16:45 -0800
> 
> > The current method of mapping the entire BAR region as a single uncacheable
> > region does not allow RDMA to use write combining (WC). This results in
> > increased latency with RDMA.
> >
> > To fix this, we initially planned to reduce the size of the map made by the
> > PF driver to include only up to the beginning of the RDMA space.
> > Unfortunately this will not work in the future as there are some hardware
> > features which use registers beyond the RDMA area. This includes Scalable
> > IOV, a virtualization feature being worked on currently.
> >
> > Instead of simply reducing the size of the map, we need a solution which
> > will allow access to all areas of the address space while leaving the RDMA
> > area open to be mapped with write combining.
> >
> > To allow for this, and fix the RMDA latency issue without blocking the
> > higher areas of the BAR, we need to create multiple separate memory maps.
> > Doing so will create a sparse mapping rather than a contiguous single area.
> >
> > Replace the void *hw_addr with a special ice_hw_addr structure which
> > represents the multiple mappings as a flexible array.
> >
> > Based on the available BAR size, map up to 3 regions:
> >
> >  * The space before the RDMA section
> >  * The RDMA section which wants write combining behavior
> >  * The space after the RDMA section
> 
> Please don't.
> 
> You have[0]:
> 
> * io_mapping_init_wc() (+ io_mapping_fini());
> * io_mapping_create_wc() (+ io_mapping_free());
> 
> ^ they do the same (the second just allocates a struct ad-hoc, but it
>   can be allocated manually or embedded into a driver structure),
> 
> * arch_phys_wc_add() (+ arch_phys_wc_del())[1];
> 
> ^ optional to make MTRR happy
> 
> -- precisely for the case when you need to remap *a part* of BAR in a
> different mode.
> 
> Splitting BARs, dropping pcim_iomap_regions() and so on, is very wrong.
> Not speaking of that it's PCI driver which must own and map all the
> memory the device advertises in its PCI config space, and in case of
> ice, PCI driver is combined with Ethernet, so it's ice which must own
> and map all the memory.
> Not speaking of that using a structure with a flex array and creating a
> static inline to calculate the pointer each time you need to read/write
> a register, hurts performance and looks properly ugly.
> 
> The interfaces above must be used by the RDMA driver, right before
> mapping its part in WC mode. PCI driver has no idea that someone else
> wants to remap its memory differently, so the code doesn't belong here.
> I'd drop the patch and let the RDMA team fix/improve their driver.
> 

Appreciate the review! I proposed this option after the original change was to simply reduce the initial size of our bar mapping, resulting in losing access to the registers beyond the RDMA section, which was a non-starter for us once we finish implementing Scalable IOV support.

Searching for io_mapping_init_wc and io_mapping_create_wc there are only a handful of users and not much documentation so no wonder I had trouble locating it! Thanks for helping me learn about it.

@Dave.Ertman@...el.com, @Saleem, Shiraz it looks like we need to drop this patch and modify the iRDMA driver's method of requesting write combined regions to use these new interfaces.

@Nguyen, Anthony L Can you drop this patch from the series on IWL or should I send a v3?

Thanks,
Jake