Jump to content

    

romez777

Свой
  • Content Count

    292
  • Joined

  • Last visited

Community Reputation

0 Обычный

About romez777

  • Rank
    Местный
  1. pskb_may_pull()

    QUOTE (Olej @ Jun 24 2017, 00:23) Комментарии говорят совсем о другом, о том, что очередь сокетных буферов может быть изменена (переставлена, перетасована). Но это вовсе не значит, что изменится хоть один конкретный struct sk_buff*. Комментарии к функции дважды это упоминают: CODE/** *    __pskb_pull_tail - advance tail of skb header * ... *    All the pointers pointing into skb header may change and must be *    reloaded after call to this function. */ /* Moves tail of skb head forward, copying data from fragmented part, * when it is necessary. * 1. It may fail due to malloc failure. * 2. It may change skb pointers. * ... */ Функция изменяет как минимум два указателя, tail и data_len, это видно из кода. QUOTE Но![/b] Кроме того, если вы лезете в такую глубину, то: - должны бы знать, что API ядра, начинающиеся с __ (2-х _) предназначены для внутреннего использования, а не для сторонних вызовов в качестве API; Такого правила, "высеченного в камне", нет. Использование функций с "__" префиксом широко практикуется в драйверах, там где это оправданно, например исключить проверки и валидации входных параметров, поскольку это уже сделано в коде драйвера. Более того, __pskb_pull_tail() экспортируемый символ, следовательно может использоваться. QUOTE - должны бы прочитать, в тех же комментариях, что это вызов сложный, экзотика и вызывается только в исключительных случаях. Эта функция вызывается из pskb_may_pull(), в чем экзотика?
  2. Комментарии к коду pskb_may_pull() на http://elixir.free-electrons.com/linux/lat.../skbuff.c#L1610 говорят, что функция может изменить skb указатели. Если так, то после выполнения этого API, нужно обновлять указатели, например, на L3/L4 заголовки. Но я просмотрел примеры использования функции в ядре, и не нашел чтобы это делали. Почему?
  3. Приветствую. Интересует, разбирался ли кто-либо подробно в OVS с целью портирования оного на железный свитч с поддержкой OpenFlow; под портированием я понимаю дописывание OVS таким образом, чтобы поиск в openflow таблицах выполнялось бы ресурсами свитча, а не софта (в ядре или в userspace). В самом OVS заложена такая возможность и даже есть соответствующий документ описывающий портирование, но там многое хотелось бы прояснить, поэтому если здесь есть товарищи с тамким опытом, pls отзовитесь.
  4. Приветствую, Система x86, линукс ядро 2.6.35 Читаю https://www.kernel.org/doc/Documentation/DMA-API.txt секцию «Part Id» про функцию dma_map_single() Там есть такие слова: CODEit is recommended that driver writers map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). Я знаю (и об этом написано в LDD), что get_free_page() гарантирует выделение памяти по границе страницы. А будет ли гарантировать подобное kmem_cache_alloc()? (Драйвер, с которым я работаю, держит небольшой buffer pool и из него черпает буферы для dma операций). Спасибо.
  5. QUOTE (des333 @ Sep 28 2013, 15:44) Не менее категорично. Маленький совет - если хотите, чтобы больше хороших спецов обратили внимание на Вашу вакансию - заинтересуйте их. Ведь переезд в Канаду ( Вы же понимаете, что на этом форуме явно немного людей, уже прошивающих в Канаде ) - дело достаточно авантюрное, поэтому должны быть какие-то очевидные преимущества для такого решения. А У Вас даже зарплата не указана Уверяю вас, те кто был заинтересован условиями, денежным вопросом и пр. связывались, проходили телефонный скрининг и получали всю необходимую информацию. QUOTE (Flood @ Sep 28 2013, 16:07) Я тут сбросил Вам в ЛС отвлеченный вопрос на тему сетевых процессоров. Посмотрите по возможности. Спасибо! Ответил, надеюсь информация вам поможет.
  6. QUOTE (x893 @ Sep 27 2013, 18:08) И не устроит. Нормальные спецы никогда не поедут - им это не надо (мне в том числе). IMHO слишком категорично. Нормалный спец это человек свободный (в том числе от уз брака) и творческий QUOTE (A. Fig Lee @ Sep 27 2013, 18:13) Берите меня. Я научусь. Так высылайте резюме, рассмотрим )
  7. Предложение все еще в силе и актуально. Были интервью с кандидатами, но уровень к сожалению не устраивал.
  8. Вакансии по-прежнему актуальны.
  9. QUOTE (Mihail Gluhowchenko @ Aug 6 2013, 09:14) NPU интересные конечно, но как то не очень понятно ваше направление. Больше похожи на консалтеров. То есть нет у вас сетевых и инфраструктурных продуктов куда бы вы могли применить данные пакетные молотилки. И что то мне подсказывает, что специалистов по железу у вас не много. Вопрос зачем? Тот же Cavium и тех партнеры поставляет достаточно готовый софт под ваши L2/L4 задачи + DPI на сколько я помню. Отвечая на ваш вопрос -- совершенно верно, компания консалтинговая, что не мешает ей тем не менее получать "большие" куски большого проекта клиента и работать над ним. Кстати, мы также являемся официальным партнером Cavium и EzChip.
  10. Приветствую, В нашу компанию http://gonorthforge.com ищутся инженеры с хорошим знанием сетевых процессоров. Если уровень действительно высокий и будет продемонстриирован на интервью, то компания возьмется за оформление рабочей визы для не-локальных кандидатов. Описание вакансий и требования здесь: http://gonorthforge.com/wp-content/uploads...de-Software.pdf http://gonorthforge.com/wp-content/uploads...ssor-_C_C++.pdf Резюме просьбма направлять на rmashak@northforgeinc.com Роман.
  11. Приветствую, достался в "наследство" сравнительно большое embedded проект (ARM процесор, linux 2.6.31, busybox), который нужно поддерживать. Столкнулся со следующей проблемой: ядерный модуль (часть этого проекта) всегда загружается первым, потом демон устанавливающий соединение по netlink сокету. Проблема в том, что после выгружения демона из памяти по SIGINT или SIGKILL, число референсов на этот модуль в ядре не 0 (cat /proc/net/modules | grep my_module, 3й параметр) и соответственно rmmod возвращает ошибку: CODE% rmmod my_module.ko % rmmod: my_module.ko: Resource temporarily unavailable Т.е. получаем -11 EAGAIN. Из кода демона известно, что открываются 3 netlink сокета в модуль и по таймеру один из сокетов регулярно читается, но после запуска демона число references в модуле (/proc/net/modules) поднимается с 0 до 6, после убийства демона опускается до 3, т.е. либо остаются открытые дескрипторы, либо что-то еще. Подскажите, какие есть методы обнаружить и отловить такого рода баг? Буду пременого благодарен!
  12. В вопросе разобрался, нашел где в ядре задаются адреса по которым будут грузиться модули (это архитектурно специфичные настройки): CODE% more arch/arm/include/asm/memory.h ... /* * PAGE_OFFSET - the virtual address of the start of the kernel image * TASK_SIZE - the maximum size of a user space task. */ #define PAGE_OFFSET             UL(CONFIG_PAGE_OFFSET) #define TASK_SIZE               (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000)) /* * The module space lives between the addresses given by TASK_SIZE * and PAGE_OFFSET - it must be within 32MB of the kernel text. */ #define MODULES_VADDR           (PAGE_OFFSET - 16*1024*1024) А вот выделение памяти под модуль: CODE% more arch/arm/kernel/module.c ... void *module_alloc(unsigned long size) {         return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,                                 GFP_KERNEL, PAGE_KERNEL_EXEC, -1,                                 __builtin_return_address(0)); }
  13. Приветствую, ядро 2.6.31.8 сконфигурировано с включенным CONFIG_VMSPLIT_3G, т.е. 1G под ядерную память и 3G под юзер спейс — соответственно ядро занимает пространство 0xc0000000 - 0xffffffff, а пользовательские процессы живут в диапазоне 0x00000000 - 0xbfffffff. Однако наблюдаю следующее: CODE# cat /sys/module/mydrv/sections/.data 0xbf00b4f4 # cat /sys/module/mydrv/sections/.text 0xbf006000 И это поведение всех драйверов на этой системе, вот так расположен марвеловский драйвер ethernet свитча на этой же платформе: CODE# cat /sys/module/mvPpDrv/sections/.text /sys/module/mvPpDrv/sections/.data /sys/module/mvPpDrv/sections/.bss 0xbf006000 0xbf00b4f4 0xbf00c3a4 Вот на всякий случай информация о процессоре: CODE# cat /proc/cpuinfo Processor       : Feroceon 88FR131 rev 1 (v5l) BogoMIPS        : 799.53 Features        : swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant     : 0x2 CPU part        : 0x131 CPU revision    : 1 Hardware        : Feroceon-KW Revision        : 0000 Serial          : 0000000000000000 Не понимаю как получается что ядерный модуль оказался загружен по user space адресам? Я предполагал, что модуль после insmod должен стать частью ядра и жить в ядерном пространстве. Возможно я ошибаюсь — просьба просветить и поправить. Спасибо!
  14. QUOTE (XVR @ Apr 4 2012, 12:55) По всему списку nhkey_list. Бежать по элементам списка и сравнивать попарно. Как только вернет нечто, отличное от 0. то это и возвращать. Если один из списков исчерпался раньше другого - возвращать -1/1 Ключ менять нельзя. Придется элемент удалить из дерева, добавить в него (в элемент) nexthop и вставить снова в дерево. Тут настоятельно напрашивается сделать ключ по чему нибудь не столь обширному и изменчивому Либо сделать так, что бы каждый отдельный nhlfe_key был представлен отдельным элементом в дереве, а ваш конечный nhlfe_entry собирать вне дерева Спасибо за ответ. А что скажете насчет следующего -- в качестве ключа _всегда_ использовать самый первый элемент списка, тот что в голове списка, сравнивать/добавлять по нему. Но возможна ситуация когда одинаковый nexthop присутствует в нескольких узлах дерева (например, один nexthop для группы IP сетей). Либо делать хеш, crc на каждый из лист-нодов, суммировать и это будет ключом. Из минусов -- каждый раз при добавлении нового nexthop'а пересчитывать ключ, удалять нод из дерева и добавлять с новым ключом. Comments are welcome