Compartilhar via


Cache de memória registrada

Os provedores de serviços SAN podem armazenar em cache buffers RDMA expostos para acesso local ou remoto para melhorar o desempenho.

Cache de buffers RDMA expostos para acesso local

A opção Windows Sockets chama a função de extensão WSPRegisterMemory de um provedor de serviços SAN em nome de um aplicativo para registrar todos os buffers de dados que servem como o buffer RDMA de recebimento local em uma chamada para a função de extensão WSPRdmaRead ou a origem RDMA local em uma chamada para a função de extensão WSPRdmaWrite . Como parte desse processo de registro, o provedor de serviços san deve bloquear esses buffers para regiões de memória física e registrá-los com a SAN NIC. Ambas as operações são intensivas em recursos. Portanto, o provedor de serviços SAN deve usar o cache para reduzir a sobrecarga desses registros. Se o provedor de serviços SAN usar cache, o desempenho de aplicativos que reutilizam buffers para transferências de dados melhorará.

Os provedores de serviços SAN devem armazenar em cache e liberar buffers RDMA expostos para acesso local, conforme descrito na lista a seguir:

  1. Quando a opção chama a função de extensão WSPDeregisterMemory para liberar um buffer, o provedor de serviços SAN deve deixar o buffer registrado com a SAN NIC e bloqueado para uma região de memória física. O provedor de serviços SAN também deve adicionar o buffer a um cache de buffers registrados, caso o buffer seja usado novamente em uma operação RDMA subsequente e a posse segura do buffer, conforme descrito no próximo item de lista.

  2. Um provedor de serviços SAN armazena em cache registros de memória com base em endereços virtuais. Quando o provedor de serviços SAN armazena em cache o registro de um buffer, o driver proxy do provedor de serviços SAN deve chamar a função MmSecureVirtualMemory para proteger a posse desse buffer registrado para que o sistema operacional notifique a opção se o buffer for liberado (por exemplo, se um aplicativo chamar a função VirtualFree para liberar um intervalo de endereços virtuais de volta para o sistema operacional).

  3. Quando a opção posteriormente chama WSPRegisterMemory para registrar um buffer, o provedor de serviços SAN deve marcar seu cache para determinar se o buffer já está registrado. Se o provedor de serviços SAN encontrar o buffer em seu cache, o provedor de serviços SAN não deverá executar nenhuma ação de registro adicional.

  4. Antes que os mapeamentos virtuais para físicos do buffer registrado sejam alterados posteriormente, a opção chama a função de extensão WSPMemoryRegistrationCacheCallback de cada provedor de serviços SAN. O driver proxy de cada provedor de serviços SAN, por sua vez, deve chamar a função MmUnsecureVirtualMemory para liberar a propriedade do buffer. Além disso, cada provedor de serviços SAN deve remover o buffer de seu cache e deve remover o registro de buffer da SAN NIC.

  5. Antes que a conexão entre um soquete SAN local e um par remoto seja fechada, o provedor de serviços SAN deve liberar todos os buffers armazenados em cache.

Nota O driver proxy deve usar o mecanismo try/except em torno do código que acessa um buffer de modo de usuário que foi protegido por meio de uma chamada para MmSecureVirtualMemory para evitar falhas no sistema operacional. Para obter mais informações sobre como um driver proxy protege e libera buffers, consulte Protegendo e liberando a propriedade de endereços virtuais.

Cache de buffers RDMA expostos para acesso remoto

A opção Windows Sockets chama a função de extensão WSPRegisterRdmaMemory de um provedor de serviços SAN para registrar todos os buffers de dados que servem como o destino rdma remoto de uma chamada WSPRdmaWrite remota ou a origem remota do RDMA de uma chamada remota WSPRdmaRead . Ou seja, a opção expõe esses buffers para acesso por um par remoto. Depois que as transferências de dados desses buffers forem concluídas, a opção chamará a função de extensão WSPDeregisterRdmaMemory do provedor de serviços SAN para liberar esses buffers para que eles não fiquem mais acessíveis do par remoto.

Os provedores de serviços SAN devem armazenar em cache buffers RDMA expostos para acesso remoto, conforme descrito na lista a seguir:

  1. Quando o Switch chama WSPDeregisterRdmaMemory para liberar um buffer, o provedor de serviços SAN deve deixar o buffer bloqueado na memória física e registrado com a SAN NIC. O provedor de serviços SAN também deve adicionar o buffer a um cache de buffers registrados, caso o buffer seja usado novamente em uma operação RDMA subsequente. No entanto, o provedor de serviços SAN deve tomar as medidas apropriadas para garantir que o par remoto não possa mais acessar o buffer. Nota Se o buffer só puder ser inacessível pelo provedor de serviços SAN removendo o registro de buffer da SAN NIC, o provedor de serviços SAN deverá fazer isso. No entanto, o provedor de serviços SAN deve deixar o buffer bloqueado para uma região de memória física. Esse cenário não fornece o melhor desempenho possível, mas é melhor do que nenhum cache.

  2. Para armazenar em cache buffers RDMA expostos para acesso remoto, o provedor de serviços SAN e seu driver proxy devem usar as técnicas de cache, conforme descrito na lista anterior para buffers RDMA expostos para acesso local.

  3. Quando a opção posteriormente chama WSPRegisterRdmaMemory para registrar um buffer, o provedor de serviços SAN deve marcar seu cache para determinar se o buffer já está registrado. Se o provedor de serviços SAN encontrar o buffer em seu cache, o provedor de serviços SAN deverá simplesmente expor o buffer para acesso remoto, nenhuma ação de registro adicional será necessária. No entanto, se o registro de buffer tiver sido removido anteriormente da SAN NIC, o provedor de serviços SAN deverá registrar o buffer novamente.

  4. Para liberar buffers RDMA expostos para acesso remoto, o provedor de serviços SAN e seu driver proxy devem usar as técnicas, conforme descrito na lista anterior.