Upstreaming do Linux Vector Packet Processor (VPP) para o FreeBSD

O Vector Packet Processor (VPP) é uma estrutura de alto desempenho para encaminhar e processar pacotes no espaço do usuário. O VPP é construído como um núcleo sobre o DPDK, mas oferece diversas oportunidades para outras interfaces de rede e possui um modelo de plug-in robusto que permite aplicativos ricos, incluindo serviços de rede e protocolos de aplicativos, como servidores web.

O VPP foi escrito como uma estrutura de alto desempenho e leva essa afirmação a sério. O núcleo do projeto é viabilizado por engenheiros da Cisco, com suporte para a organização da Linux Foundation. Com esta equipe por trás do projeto, eles podem oferecer integração e testes contínuos abrangentes e um processo de regressão de desempenho chamado CSIT, que testa continuamente o VPP em uma seleção de hardware para descobrir e resolver alterações prejudiciais.

Este artigo descreve o processo de código aberto e upstreaming da porta VPP para o Projeto VPP; uma discussão técnica do trabalho necessário para portar o VPP para o FreeBSD está disponível no gêmeo deste artigo.

Este projeto levou vários meses para fazer a portabilidade principal e corrigir problemas no VPP, DPDK e FreeBSD, que foram revelados por meio de testes. O porto melhorou as três plataformas para todos os usuários e transferiu as alterações para os projetos relevantes. Esta atividade criou mais de 100 mudanças de código aberto e não teria sido possível por um voluntário em seu tempo livre.

Com seu co-patrocinador RGNets, a fundação FreeBSD me contratou para portar o VPP para o FreeBSD e fazer o upstream do código para o projeto VPP.

Portando VPP para FreeBSD

Desde o início deste projeto, decidi entrar no VPP e começar a fazer alterações. Meu objetivo era agir rapidamente. Embora não tivéssemos conhecimento de quaisquer problemas centrais que tornariam impraticável uma portagem VPP para o FreeBSD, duas tentativas anteriores não tiveram sucesso.

Eu queria que o VPP funcionasse no VPP o mais rápido possível e reconhecia a dívida técnica criada desde o início para fazer o código funcionar antes que ele pudesse ser transferido para o VPP.

Trabalhei em público com um branch do GitHub ocasionalmente sincronizado que chamei de branch “wip”. No final de janeiro de 2024, este ramal começou a estabilizar, com as alterações exigidas a tornarem-se muito menos abrangentes do que no início do porto.

No final de janeiro, trabalhei em todas as mudanças no branch WIP, importando-as em pequenos pedaços lógicos que eu esperava que fossem fáceis de revisar em um projeto upstream e colocando-os em meu branch “freebsd-build”. Esta ramificação representa todas as mudanças que eu esperaria passar da porta para o upstream do VPP. Assim que este branch ficou pronto, coletei algumas pequenas mudanças específicas do FreeBSD necessárias para adaptar o VPP como era para o FreeBSD CURRENT e os branchs estáveis ​​existentes do FreeBSD; este ramo é chamado “freebsd-vpp”.

Depois de limpar a construção da filial “freebsd-vpp”, eu estava pronto para fazer uma chamada pública para testes e começar a falar sobre o projeto VPP.

Comunidade VPP

O projeto VPP está organizado. A Cisco emprega vários engenheiros para trabalhar na tecnologia principal e fornecer orientação para o projeto. No entanto, este não é um programa exclusivo da Cisco; há muitos colaboradores de outras organizações.

O VPP mantém uma lista de discussão pública sobre desenvolvimento e duas reuniões abertas regulares. Uma delas é para sua análise de regressão contínua, chamada CSIT. É uma chamada eficiente que rastreia problemas na infraestrutura de teste e garante que o VPP continue a atingir suas famosas metas de desempenho. A segunda é a teleconferência da comunidade VPP, que acontece duas vezes por mês, na segunda e quarta terças-feiras. A chamada comunitária rastreia problemas e funciona como uma sessão de escritório aberto para os recém-chegados ao projeto.

A Fundação FreeBSD anunciou o porte do VPP como trabalho contínuo e, logo depois, anunciei uma chamada para testes do projeto FreeBSD na lista freebsd-net e do VPP na lista de discussão vpp-dev.

Na semana seguinte à minha participação na convocatória da Comunidade VPP, fui calorosamente recebido pelo projeto. Descrevi a mudança que queria fazer, adicionando suporte ao FreeBSD, e como planejei enviar o novo código.

Fui recomendado a criar alterações pequenas e de fácil digestão para revisão e recebi dicas sobre como marcar as pessoas relevantes para revisão.

Recebi uma análise e um ótimo feedback quando comecei a implementar as mudanças. Um bônus que eu não esperava é que as mudanças necessárias para suportar o FreeBSD fizeram com que os engenheiros do VPP atualizassem a infraestrutura central do VPP para ser mais flexível. Isso superou alguns dos meus patches, mas tornou o código VPP muito mais agradável de ler.

Trabalhando com upstream

Em 2024, está mais claro do que nunca a importância de uma boa relação de trabalho com um upstream se você deseja contribuir com código. Tenho trabalhado no FreeBSD há alguns anos e ajudei muitas organizações a inserir o código em nossa árvore de origem.

Como mantenedor, estou sempre procurando algumas coisas:

• pequenas mudanças independentes
• testando
• mensagens de commit autodocumentadas

Tentei deliberadamente transformar meu “ramo de pesadelo” de 10 mil linhas em pequenas mudanças independentes. Isso transformou meu trabalho em pequenas e agradáveis ​​mudanças, muitas das quais eram de apenas uma ou duas linhas (obter o emblema XS no gerrit).

Felizmente, minhas mudanças para habilitar o FreeBSD se concentraram principalmente em fazer com que o VPP fosse compilado, então eu não precisei me preocupar com as consequências da compilação do FreeBSD ainda. Em sua maioria, também foram alterações independentes, o que tornou a revisão muito fácil. As coisas são sempre muito mais difíceis se você tiver um grande conjunto de patches que deve ser atualizado a cada comentário de revisão.

Lancei alterações em lotes no projeto VPP, plenamente consciente do trabalho adicional que estava criando para os mantenedores do VPP a cada alteração.

Tomei medidas não técnicas para ajudar o projeto a entender quem eu era, por que as mudanças estavam sendo feitas e meus objetivos finais. Antes de enviar qualquer alteração, enviei um e-mail de anúncio para a lista de discussão vpp-dev com uma visão geral e explicação do que eu faria.

Participei das chamadas da comunidade do VPP e, sempre que possível, tentei ajudar outras pessoas com seus problemas de trabalho no VPP.

A partir deste trabalho, formei relacionamentos bons e amigáveis ​​com desenvolvedores de VPP, o que melhorou muito o processo de revisão. É sempre bom poder anexar uma voz a um comentário de revisão de commit — isso dá mais contexto que sempre falta em uma mídia somente texto.

Progresso do Porto

O upstreaming de alterações no VPP está indo bem. Depois de alguns meses, temos cerca de 20% das alterações originais para mesclar. Uma vez que o VPP pode ser baseado no VPP, o projeto nomeou algum hardware para atuar como um dispositivo de teste e construção de CI. Este é um passo importante para que a portabilidade seja aceita e se mantenha atualizada à medida que o VPP continua a se desenvolver.

Foi incrível trabalhar com o projeto VPP. Em particular, gostaria de agradecer a Dave Wallace por suas boas-vindas e entusiasmo com a ideia de um novo sistema operacional para VPP e Damjam Marion por sua ajuda na revisão e implementação de mudanças para habilitar o VPP no FreeBSD.

Minha fila original de 100 alterações é muito em que pensar e uma quantidade significativa de trabalho para passar pela revisão do código. Este esforço foi possível graças ao apoio da Fundação FreeBSD e do co-patrocinador do projeto RGNets.