Re: [External] [LSF/MM/BPF BoF] Session for CXL memory

["Viacheslav A.Dubeyko" <viacheslav.dubeyko@bytedance.com>]

> On Jan 24, 2023, at 2:12 AM, Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> 
> On Fri, 6 Jan 2023 14:20:42 -0800
> "Viacheslav A.Dubeyko" <viacheslav.dubeyko@bytedance.com> wrote:
> 
>> CC: LSF/MM/BPF mailing list. Sorry, missed the list.
>> 
>>> On Jan 6, 2023, at 11:51 AM, Viacheslav A.Dubeyko <viacheslav.dubeyko@bytedance.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I believe CXL memory is hot topic now. I believe we have multiple topics
>>> for discussion. I personally would like to discuss CXL Fabric Manager
>>> and vision of FM architecture implementation. 
> 
> The fabric manager is rather disconnected from the host side of things (all
> out of band communications), so it would be a stretch to build a stand alone
> topic around that for LSF-MM. If we have the right people in the room /
> online, it would be good to discuss it (so part of a wider sessions on CXL).
> I'd love to get some traction before LSFMM though! Host aspects such as
> Dynamic Capacity Devices and sharing feel more LSFMM suitable.
> 
>>> I am going to share the topic in separate email.
> 
> Did I miss the email, or not sent yet?  That topic is obscure enough we definitely
> need some background if anyone outside of CXL folk is going to have any idea what
> we are talking about.
> 

You missed nothing. :) I am still polishing the FM related topic. Sorry, I was busy
with other tasks. 

>>> would like to suggest a special session for CXL memory
>>> related topics.
>>> 
>>> How everybody feels about it?
> 
> A lot of the interesting bits currently strike me as rather speculative
> (no code), so sessions might not be as productive as shooting at an
> implementation. That's less true of FM stuff as we really do need
> an outline of an architecture plus some planning on that.
> 
> Could we have something to shoot at for other topics in the
> time frame?  maybe...
> 

I believe even discussion before implementation could make sense.
Because, it provides the way to make the architecture/API vision more
clear and understandable by everyone sometimes. :)

Thanks,
Slava.