Til

http://www.cisco.com/c/en/us/products/collateral/routers/cloud-services-router-1000v-series/datasheet-c78-733443.html How many vCPUs are required for processing.

Data sheet (PDF) Some Cisco virtual network services that use the DPDK include Cisco Cloud Services Router (CSR) 1000V, Cisco Virtual Mobile Packet Core software, and Cisco IOS® XR 9000v virtual router. Supporte CISCO appliances Cisco Cloud Services Router (CSR) 1000V virtual router Cisco Virtual Adaptive Security Appliance (ASAv) Cisco Prime™ Data Center Network Manager (DCNM) Cisco Virtual Network Analysis Module (vNAM) Cisco Virtual Security Gateway (VSG) for Cisco Nexus® 1000V Switch deployments Cisco Virtual Supervisor Module (VSM) for Cisco Nexus 1000V Switch deployments 1U 2 CPU, each has 8 core Ivy Bridge(E5-2630 v3) REST API It uses REST API and NETCONF protocol for north-bound management and orchestration (MANO) tools.

철학의 부재. 중심의 부재. 대화의 부재 제품을 만드는데 철학이 없다는 건 정말 큰 문제다. 누군가 대충 스케치만 그린 그림을 가지고 차를 만든다고 생각하면 끔찍하다. 각 부분 부분별로 , 기능 별로 어떻게 만들 것인지 고민없이 그냥 각 부서별로 자기가 맡은 걸 만든다면 그 차가 굴러가기만 해도 기적이지만, 제대로 굴러가는 커녕 일정 내 만들어질 리가 없다. 처음부터 끝까지 혹은 적어도 그걸 만드는 사람들이 충분히 제품의 철학(성격 등)을 공감할 때까지 끊임없이 대화해서 그나마 비슷한 생각을 가진 후에야 각 기능별 부분별 설계가 이뤄져야 한다.

잘못된(?) 진단은 잘못된 처방을 낳는다. 모든 걸 개인의 잘못으로 돌리려는 의도는 의외로 단순. 잘못을 저지른 개인은 개선시키면 된다는 단순한 해법을 제시할 수 있으므로. 개인을 구박하거나 심지어는 그 조직에서 제외시키면 문제가 해결(?)되는 것처럼 보이니까. 하지만 그 뒤에 숨어있는 실은 개인의 잘못으로 돌려진 관리의 문제, 시스템의 문제는 아무도 건드리지 않는다. 문제의 원인이 너무 커서, 문제의 원인이 너무 근본적이라, 문제의 원인이 권력자에게 있는 터라. 그렇게 문제는 반복된다. 비난의 대상이 되는 ‘개인’만 바뀔 뿐. 병든 조직은 서서히 그렇게 스러진다…

관리자들이 개발자들을 위해 한 일이 뭐가 있나? 아무리 생각해도 잘 모르겠다. 그럼 개발자를 위한 사람이나 제도는 없다는 건데 그러면서 개발자가 잘 하기 기대하는 건 도둑놈 심보가 아닌가? 자꾸만 벗어나길 원하는 ‘개발’업무를 만든 게 누구인지? 왜 그렇게 된 건지? 이런 근본적인 질문에 대한 고민과 해결 없이 SW품질을 논한다는 건 어불성설이다.

규제를 풀기 어려운 이유는 그 규제를 풀어도 문제가 없는 지 자신이 없기 때문이다. 증명하기 어려운 경우가 대부분. 하지만 머리를 맞대고 함께 이야기해봐야 한다. 정말 필요한 절차인지 고민해야 한다. 가능하면 절차는 줄이고 또 줄여야 한다고 생각. 이런 고민조차 어려운 이유는 대부분 한 쪽이 들으려 하지 않기 때문. 기존에 하던 (불필요해보이는) 절차를 없애는 경우 발생할 수 있는 위험요소를 감수할 의지가 없으므로. 혹시 이렇게 생각하고 있는 건 아닌지 그런 번거로운 절차는 내가 하는 게 아니라 니들이 하는 거니까

TAILQ_HEAD(ip_pkt_list, ip_frag_pkt); /**< @internal fragments tailq */ 자료 구조체 Fragment 관리용 table struct rte_ip_frag_tbl *frag_tbl; locking 없이 IP reassembly를 수행할 단위(통상 core)로 한 개씩 만든다. 즉 하나의 core가 여러 rx queue를 처리하더라도 하나의 frag_tbl만 가지면 된다. 아래 rte_ip_frag_table_create()함수를 이용해서 생성한다. struct rte_ip_frag_death_row death_row core별로 갖는 death_row. IP reassembly를 호출한 후 해당 함수내에서 free할 mbuf를 이 리스트에 담아줌. main loop에서 reassembly작업 후 rte_ip_frag_free_death_row()함수를 호출해 reassembly에 실패한 mbuf를 free함 IP_MAX_FRAG_NUM defines the maximum fragments of one reassembly.

자네는 Agile이 뭔지, Scrum Master가 어떤 일을 해야 하는 지 모르겠지만, 앞으로 자네를 ‘Scrum Master’라고 부르겠네. 이제 우리는 Scrum Master를 가졌으니, Agile을 하는 걸쎄 글쎄요… 저도 Agile을 잘 모르지만, 동의할 수가 없네요. 국정교과서의 필요성에 대해 이야기하는 이상한 나라의 사람들 만큼이나 이해하기 어렵네요.

We can’t measure Programmer Productivity… or can we? LOC The more fundamental problem is that measuring productivity by lines (or Function Points or other derivatives) typed doesn’t make any sense. A lot of important work in software development, the most important work, involves thinking and learning – not typing. The best programmers spend a lot of time understanding and solving hard problems, or helping other people understand and solve hard problems, instead of typing.

예 ipsec on asf/se/… 불럭별 특징이 아니라 프로토콜별 호환성이나 주의사항에 대한 취합 필요 보통 postmortem하면 그 블럭의 특징이라고 보는 경향이 강한데 그것과 무관하게 프로토콜 특성에 대한 내용은 블럭 설계와 별개로 모아놔야 하지 않을까? StackOverflow 처럼 분야별로…