On 1/9/2024 8:05 PM, Leon Romanovsky wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Mon, Jan 08, 2024 at 09:40:32PM +0200, Leon Romanovsky wrote: >> >> On Mon, Jan 8, 2024, at 20:06, Jason Gunthorpe wrote: >>> On Mon, Jan 08, 2024 at 08:01:40PM +0200, Leon Romanovsky wrote: >>>>> I was saying in the rdma-core PR that this field shouldn't even >>>>> exist.. >>>> Something like that? >>> Yeah, like that. However it is difficult to get the out valid uattr >>> back in the rdma-core side. >>> >>> This is best if the ID's can have well defined not-valid values such >>> as 0 or -1. >> Michael tried something like that in previous versions by defining 0xffff as not valid. >> >> I didn't like it because there's no promise from PCI core that it is invalid value. > Michael, > What do you think? > > Thanks In this case I prefer to keep the explicit validity for consistency with the device originated values. In general I think it will be useful to have some convenient way to get attr validity from the ioctl mechanism in rdma-core. Michael
